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I.  INTRODUCTION 


Recognizing  tne  relatlonsnip  between  policies  and 
mechanisms  nas  been  a  problem  in  tne  specification  and 
design  of  many  computer  systems.  Vnat  is  needed  is  a  simple 
methodology  for  assessing  the  suitability  of  a  protection 
mechanism  to  enforce  a  non-dlscretionary  security  policy. 
Such  a  methodology,  based  upon  the  entity-relationship  model 
and  designed  with  validation  of  security  enforcement  as  its 
primary  objective,  is  presented. 

Defined  as  the  assignment  technique,  this  mathematically 
oriented  metnodology  establishes  a  relationship  between  tne 
information  sensitivities  of  the  systems  entities 
(partitioned  according  to  the  policy  constraints),  to 
dominance  domains  (inherently  established  by  a  mechanism). 
The  assignment  tecnnique  provides  a  means  for  mecnanlsm 
sufficiency  validation,  since  the  results  of  tne  assignment 
can  be  evaluated  to  determine  wnetner  tne  constraints  of  tne 
policy  are  met. 

Mechanisms  are  defined  as  procedural  specifications  that 
prevent  tne  occurrence  of  operations.  Protection  mechanisms, 
then  control  a  subject's  access  to  an  object,  by  adhering  to 
some  procedural  specification  of  access  rules.  Policies, 
however,  are  generally  stated  la  a  non-procedural  form.  This 
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leads  to  a  problem  in  translating  policies  into  mecnanisms, 
and  in  verifying  the  accuracy  of  this  translation. 

Only  non-discretlonary  security  policies  are  discussed 
in  detail.  Suca  policies,  however,  are  extremely  Important 
wnen  dealing  with  protection  of  business  information  as  well 
as  National  Security.  Computer  systems  designed  to  provide 
Cotinaad,  Control  and  Communications  must  rely  upon  effective 
non-discreti onary  security  if  tney  are  to  be  of  any  value  to 
National  Defense  [lj .  Compromise  and  subversion  policies  [2J 
precisely  define  tne  requirements,  but  tne  suitability  of  a 
protection  mecnanlsm  to  meet  taese  requirements  is  not 
always  apparent,  i  theoretical  foundation  from  which  this 
suitability  may  be  simply  and  readily  derived  is 
established. 

A.  BACKGROUND 

Non-discretionary  policies  for  tne  security  of  sensitive 
information  have  existed  throughout  tne  annals  of  history. 
The  basis  of  these  policies  lies  in  a  subject  (l.e.,  an 
active  entity)  bein*  prohibited  modification  or  observation 
of  an  object  (l.e.,  a  repository  for  information  or  inactive 
entity)  based  upon  the  subject's  membership  in  a  specified 
eroup.  This  eroupin*  is  established  external  to  tne  system 
in  which  it  will  be  used. 

The  first  computer  systems  dealt  with  the  problem  of 
security  by  establishing  physical  protection  perimeters. 
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Walls,  loess  and  marines  with  rifles  provided  the 
environment  necessary  for  system  security.  Tnis  was  an 
acceptable  procedure  because  there  were  relatively  few  users 
of  tne  system  and  eacn  user  was  trusted  not  to  violate  tne 
security  policies.  Security  was  an  issue  external  to  tae 
computer  itself. 

However,  as  computer  technology  became  more 
sophisticated,  user  expectations  increased.  Pollcy-ma Kers 
established  security  policies  and  expected  their  machines  to 
adhere  to  them  without  exception.  The  security  perimeters 
that  had  been  established  external  to  tne  computer,  were  now 
to  be  established  Internally. 

This  led  to  two  fields  of  researen.  One  group,  tne 
experimentalists,  attempted  to  design  ingeniously  contrived 
mecnanisms  with  little  or  no  concern  for  tne  policies  wnicn 
their  mechanism  would  support.  Mathematicians,  on  the  other 
nand,  set  about  tne  task  of  modeling  policies  in  a  fasnlon 
that  would  establish  a  foundation  for  the  procedural 
specification  of  protection  mechanisms.  The  relationship 
between  these  models  and  the  mechanisms  was  not  always 
clear. 

What  is  needed,  and  wnat  is  presented  nere,  is  a  simple, 
complete  and  consistent  means  of  establishing  that  a 
mechanism  actually  enforces  tne  policy-mafcers ' 
specifications.  This  is  done  by  first  giving  the 
policy-maker  a  tool  to  precisely  describe  nis  policy  and 
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then  giving  tne  systems  designers  and  analysts  a  technique 
to  evaluate  the  sufficiency  of  their  mechanism  to  support 
tnls  policy. 

A  careful  examination  of  tne  fundamental  nature  of 
non-dlscretionary  security  policies  and  protection 
mechanisms  is  made.  This  examination  is  based  largely  upon 
the  flndines  of  research  associated  with  security  Kernel 
tecnnology  [3J .  The  results  of  this  examination  snow  wnat  it 
is  about  mechanisms  that  actually  provides  the  protection 
and  what  protection  is  actually  provided.  In  so  doin*,  a 


theoretical  mathematical  foundation  is  established 
which  the  science  of  secure  computation  may  proceed  to 
tne  requirements  of  tne  policy-mater  in  a  simple,  el 
and  efficient  manner. 


from 
mee  t 
egant 


B.  RELATED  WORK 

Research  in  establishing  the  suitability  of  protection 
mecnanlsms  to  meet  non-discretionary  security  policies  is 
practically  non-existent.  Protection  mechanisms  are  usually 
presented  in  an  informal  manner  witn  implementation  details 
dominating  tne  discussion  [4j  .  Policies,  on  tne  other  hand, 
are  generated  by  persons  wno  rarely  give  consideration  to 
the  implementation  of  these  policies  in  a  computer  system. 
The  disparity  between  tnese  two  groups  has  led  to  little 
research  in  methodologies  for  bridging  the  broad  gap  between 
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security  policies  and  protection  mecnanisms ,  and  even  less 
results. 

The  notion  of  domains  originated  with  Dennis  and  Van 
Horn  [5J  and  tneir  concept  of  spneres  of  protection.  Tnis 
idea  was  improved  upon  by  Lampson  [6,?J  wno  coined  the  term 
’’domain’’  and  noted  tae  usefulness  of  domains  as  a  conceptual 
tool  for  understanding  protection  mecaanisms.  Scnroeaer  [HJ 
made  use  of  tnese  ideas  to  design  a  protection  mecnanism 
tnat  would  allow  mutually  suspicious  subsystems  to  cooperate 
in  a  single  computation. 

Popes  [9J  modeled  tne  nature  of  access  control  wi tn  ni s 
restriction  eraphs.  Beil  and  LaPadula  110J  made  a 
significant  contribution  wnen  tney  identified  a  matnemati cal 
framework  witnin  w&ich  to  deal  wltn  tne  problems  of  secure 
computer  systems.  Tneir  work  was  based  upon  general  systems 
tneory  and  finite  state  automata.  Furtek  [llj  established  a 
similar,  less  known,  mathematical  framework  based  upon  tae 
theory  of  constraints.  Tne  Bell  and  LaPaauia  work  was 
followed  by  Walters  [12J  development  of  a  lattice  model  for 
security  policies.  This  model  was  refined  and  later 
popularized  by  Dennine  [13]  such  that  today,  nearly  all 
practical  policies  nave  been  recognized  as  lattice  policies. 

Saltzer  and  Schroeder  114]  presented  a  tutorial  on  the 
basic  principles  of  protection  in  computer  systems.  Conen 
[15],  however,  provides  a  far  more  rieorous  discussion  of 
protection  mecnanisms  wnile  Gronns'  [16]  research  provides 
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considerable  insignt  into  a  number  of  details  regarding 
access  relations. 


Mucn 

of 

this  early  work  was 

directed 

towards 

tne 

solution 

of 

the  computer  security 

problem 

in  National 

Defense 

[12, 

1? J  .  As  such,  tne  authors 

rareiy 

discused 

tne 

motivation  for  taeir  efforts.  It  was  Scaeil  UJ ,  aowever, 
wno  dramatically  described  tne  importance  of  tne  computer 
security  in  a  modern  electronic  environment.  Recognition  of 
tne  significance  of  tnls  problem  motivated  tne  researcn 
reported  aere. 

C.  ORGANIZATION 

Tne  relationsnip  between  security  policies  and 
protection  mechanisms  is  not  obvious.  In  order  to  explore 
this  relationship,  one  must  clarify  tne  meaning  of  security 
and  protection.  Only  by  methodically  examining  each  and 
every  pertinent  principle  can  one  nope  to  establish  a 
mathematical  frameworlc  which  unifies  the  security  policy 
Issues  with  tae  protection  mechanisms'  design. 

The  nature  of  non-discretionary  security  policies  is 
considered  first.  Tne  meaning  of  access  relations  is 
explored  and  commonly  known  policies  are  discussed. 

Next,  a  formalized  notion  of  domains  is  presented.  A 
succinct  mathematical  definition  of  a  domain  is  offered.  The 
notion  of  an  (access-mode)  domain  and  dominance  domains  are 


13 


introduced  as  tools  for  precisely  cnaracteri zing  protection 
mechanisms. 

Section  four  discusses  tne  tneoretical  oasis  for 
assignment.  The  assignment  tecnnique  is  explained  and  a 
means  for  simplifying  tne  tne  number  of  assignment  scnemes 
needed  to  establish  tne  insufficiency  of  a  mechanism  to 
support  some  particular  policy  is  derived. 

Section  five  presents  detailed  applications  of  simple 
assignment  snowine  tne  usefulness  of  tne  assignment 
tecnnique  particularly  vitn  respect  to  mecnanism  sufficiency 
validation.  Section  five  dispells  mucn  of  tne  mystery  teat 
surrounds  tne  ad  noc  design  of  secure  computer  systems. 

Every  attempt  has  been  made  to  provide  the  reader  with  a 
clear  understanding  of  tne  principles  of  the  assignment 
technique.  Readers  are  encouraged  to  question  these  findings 
and  indeed,  the  fundamentals  upon  which  they  are  based.  Only 
In  so  doing,  can  one  nope  to  grasp  tne  meaning  of  tne 
principles  presented  and  the  utility  of  the  assignment 
technique  in  establishing  a  foundation  for  secure  computer 
systems. 
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II.  NON -DISC RET ION ART  SECURITY  POLICIES 


Tnis  section  provides  a  detailed  examination  as  to  tne 
nature  of  non-discretionary  security  policies  after  first 
discussing  several  pertinent  concepts  concerning  policies  in 
general.  Some  of  tne  issues  presented  may  appear  to  confuse 
policy  Issues  vitn  mecnanlsm  issues.  Hopefully,  tnis 
confusion  will  toe  resolved  as  tne  reader  obtains  a  thorough 
understanding  of  tne  lnnerently  isomorpnic  nature  of 
policies  and  mechanisms,  as  substantiated  in  tne  ensuing 
discussion. 

A.  THE  NATURE  OF  A  POLICY 

The  fundamental  nature  of  a  policy  nas  not  been  clearly 
establlsned  in  tne  Computer  Science  field.  For  example, 
Wulf,  Cohen,  Jones  and  otners  sueeest  that  a  policy  is  a 
mecnanism  wnen  discussing  HYDRA  [1BJ  .  Jones  subsequently 
discusses  how  protection  mechanisms  can  be  used  to  enforce 
security  policies  [19J .  On  tne  otner  nand,  Conen  defines  a 
policy  as  a  problem  in  his  doctoral  dissertation  [15]  but, 
enumerates  several  protection  problems  associated  vitn  one 
security  policy  [15].  Such  confusion  among  such  a  closely 
related  eroup  of  computer  scientists  specializing  in 
operating  system  security  is  by  no  means  an  isolated 
situation. 
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Snyder  [20J  mases  note  of  tnis  problem  stating  tnat 


capabili ty-based  protection  systems  designers  rarely 
consider  tbe  security  policies  tneir  system  may  implement. 
Throughout  the  computer  security  literature,  one  may  coserve 
that  the  nature  of  a  policy  and  now  It  relates  to  the 
protection  issues  discussed,  is  often  ignored.  Pernaps  tnis 
is  because  the  nature  of  security  policies  themselves,  and 
tne  suitability  of  protection  mecnanisms  to  meet  tnese 
policies  is  not  clearly  understood.  It  is  the  intent  of  tnis 
autnor  to  address  tnis  problem.  In  order  to  do  so,  one 
beelns  by  formalizing  tne  notion  of  a  policy. 

A  policy  is  a  specification  of  benavlor.  Sucn  a 
specification  constrains  tne  activities  witnin  a  system  by 
establisnlng  a  distinction  between  acceptable  ar.d 
unacceptable  behavior  for  some  set  of  classes  established  by 
the  policy.  tfhen  dealing  with  tne  security  issue,  tne 
classes  (i.e.,  access  classes)  are  simply  labels  wnicn  the 
policy  uses  to  llstineuisn  between  croups  of  system 
entitles.  So  a  security  policy  specifies  a  set  of  access 
classes  and  identifies  tne  acceptable  behavior  between  them. 

Enforcement  of  policies  may  be  realized  in  a  number  of 
ways.  In  general,  any  means  of  security  enforcement  internal 
to  tne  computer,  may  be  considered  to  be  a  protection 
mechanism.  As  such,  implementation  details  are  generally 
Ignored. 
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Toe  term  behavior  generally  implies  mat  an  active 
entity  is  dealing  vita  some  otner  entity  or  entities.  So  one 
can  distinguish  between  two  types  of  entitles  witn  respect 
to  security  policy  specifications.  One  type  is  tnose 
entities  whose  benavior  is  being  controlled.  These  are  tne 
active  entities  within  the  system  and  are  referred  to  as 
"subjects".  The  otner  type  is  tnose  witn  wmcn  tne  subject 
interacts  during  execution  that  are  not  subjects,  but  rather 
are  simply  repositories  of  information  [12] .  These  are  tne 
passive  entities  within  the  system  referred  to  as  ’’objects’’. 

A  process  is  characterized  by  an  address  space  and  an 
execution  point  or  state  of  its  virtual  processor.  It  is 
Important  to  note  tne  distinction  between  processes  and 
subjects  as  these  two  terms  are  often  incorrectly  considered 
to  be  synonyomous.  A  subject  is  implemented  as  a 
process-domain  pair  [6,7,8].  One  must  tafce  care  not  to 
confuse  tnese  two  terms. 

Much  confusion  has  been  associated  with  the  issue  c f 
policy  enforcement.  A  policy  may  be  completely  enforced  in  a 
system,  partially  enforced  in  a  system  or  not  enforced  at 
all.  Partial  enforcement  applies  only  to  complex  policies 
for  vnlcn  sub-policies  can  be  formulated  and  enforced. 
Partial  enforcement  does  not  imply  enforcement  of  a  policy 
only  under  certain  conditions,  or  at  certain  times,  wnicn 
is,  in  fact,  no  enforcement  at  all.  Partial  enforcement 
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refers  to  enforcement  of  a  sub-policy  witnin  tne  context  of 
the  overall  policy. 

Policies  are  not  problems  [15] .  Problems  occur  only  in 
the  implementation  of  a  policy  and.  are  used  to  describe 
pitfalls  in  tne  enforcement  of  some  policy  of  interest. 

Applying  some  policy  to  a  system  mates  no  changes  to 
tnat  system  at  tne  time  of  application.  Tnis  means  tnat 
policies  do  not  initially  alter  the  entities  with  which  they 
deal.  Rather,  entities  are  assigned  to  an  access  class 
according  to  the  policy.  If  an  entity  is  assigned  to  an 
access  class  sucn  that  its  attributes  require  modification, 
or  its  relationships  are  invalid,  or  the  entity  itself  does 
not  belong  witnin  tne  system,  tne  system  is  not  in 
compliance  with  the  policy.  Action  may  be  taxen  later  to 
bring  tne  system  into  compliance,  but  simply  associating  tne 
policy  with  tne  system,  in  effect,  only  labels  tne  system 
entities. 

Recognizing  the  nature  of  a  policy  is  important  if  one 
is  interested  in  enforcement  of  policies  in  computer 
systems.  This  is  because  tne  logical  nature  of  a  computing 
device  dictates  a  logical  specification  of  policy.  Having 
clearly  described  tne  nature  of  a  policy  in  general,  one  may 
now  examine  security  policies. 


B.  SECURIT?  POLICIES 


Security  policies  are  generally  grouped  into  two  broad 
classes.  Non-discretionary  security  policies  (sometimes 
referred  to  as  mandatory  policies),  are  policies  which  fix 
tne  classification  of  information  sensitivities  and 
establisn  all  permissible  access  relations  (vi2.,  subjects 
gaining  some  form  of  access  to  objects)  according  to  tnese 
information  sensitivities.  Sucn  a  policy  is  generally 
considered  to  externally  constrain  wnat  access  is 
permissible  [3J.  Enforcement  of  a  policy  requires  tnat  tne 
sensitivity  of  all  objects  and  tne  autnori zat ions  of  all 
subjects  be  clearly  identified. 

Discretionary  policies,  in  a  sense,  provide  a  finer 
granularity  of  access  control  vitnln  tne  constraints  of  tne 
non-discretionary  policies  of  tne  system  [3J  .  Autnori za tion 
to  access  information  and  specification  of  source 
information  access  classes  are  made  outside  of  tne  computer 
environment.  A  policy  is  discretionary  vnen  a  subject  vim 
access  to  an  object  may  exercise  its  discretion  in  making 
tnat  object  available  to  some  otner  subject.  As  sucn,  tne 
information  sensitivity  of  an  object  is  decided  in  a 
discretionary  or  arbitrary  manner.  Tnis  tends  to  produce 
"spaghetti  bowl"  policies  where  tne  information 
sensitivities  of  objects  is  not  easy  to  determine.  The 
sensitivity  of  objects  is  constantly  changing  in  an 
arbitrary  manner  which  may  not  be  readily  observable  or 
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controllable.  Sucn  policies  are  not  practical  wnen  dealing 
with  many  of  tne  National  Defense  issues.  Because  of  their 
limited  utility,  discretionary  policies  are  not  as 
interesting  as  non-iiscret iona ry  policies  nor  is  their 
enforcement  sucn  a  critical  issue. 

Only  non-discretionary  security  policies  are  examined  in 
tnis  discussion.  It  is  snown  tnat  all  con-discretior.ary 
security  policies  can  be  represented  as  lattice  security 
policies. 

C.  LATTICE  SECURITY  POLICIES 

A  number  of  non-discretionary  security  policies  have 
already  been  described  as  lattice  policies  [12,21J .  As  sucn, 
the  precise  form  of  the  lattice  structure  is  helpful  in 
understanding  tne  nature  of  tne  policy  [19J . 

A  universally  bounded  lattice  is  a  mathematical 
structure  consisting  of  a  finite,  partially  ordered  set  for 
which  tners  exists  precisely  one  least  common  upper  element 
(i.e.,  tne  least  upper  bound  (LUB))  and  precisely  one 
greatest  common  lower  element  (i.e.,  the  greatest  lower 
bound  (3LB))  [22.23J .  A  partially  ordered  set,  is  a  set,  0, 
for  which  a  relation,  R,  is  applied  to  Q  such  that  R  is 
reflexive,  antisymmetric  and  transitive  [22J .  For  example, 

consider  the  set  Q  *  {  q,t  q  q  .  q,  }  and  the  relation  R 

12  3  4 

applied  to  0  sucn  that  <l1Rd2  (I.e.,  q^^  is  related  to  q^  by 

relation  R),  q,Rq  .  q,  Rt(,  ,  Rq,  ,  and  q  Rq  .  The  relation  R 
131424  34 
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forns  a  lattice  on  tne  set  3  vita  q  as  tne  GIB  ana  q  as 


Vnen 

discussing 

lattice 

security 

policies,  one 

recognizes 

tne 

set 

3  as 

tne 

set  of 

access  classes 

esta  blisned 

by 

the 

policy. 

The 

access  relation  R,  however, 

may  vary  significantly  from  policy  to  policy.  Tnis  fact  is 
not  so  veil  recognized.  Dennings  information  flow  model 
[13J  ,  for  example,  describes  a  flow  relation,  defined 

on  pairs  of  access  classes  sucn  that  for  classes  A  and  B,  A 
— >  3  if  and  only  if  information  in  class  A  is  permittee  to 

flov  into  class  B.  Tfils  relation  applies  to  compromise  and 
subversion  policies,  for  example,  out  is  meaningless  vnen 
discussing  program  integrity. 

Tnree  relations  between  access  classes  are  generally 
sufficient  to  describe  tne  specifications  of  any 
non-discretionary  security  policy.  For  access  classes  A  and 
B,  tnese  are  : 

A  >  B  Information  of  access  class  A 
is  more  sensitive  man 
information  of  access  class  B 

A  =  B  Information  of  access  class  A 
is  of  tne  same  sensitivity  as 
information  of  access  class  B 

A  ft  B  Information  of  access  class  A 
Is  in  no  way  related  to 
Information  of  access  class  B 

The  notion  of  sensitivity  may  be  easily  confused  vnen 
discussing  several  policies.  Tnis  is  because  tne  term  taires 
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its  meaning  from  the  policy  in  question  and  cannot  be 
readily  associated  witn  two  diverse  policies.  For  example, 
an  object  0  may  be  >  a  subject  S  witn  respect  to  one  policy, 
#  witn  respect  to  anotner  policy,  and  S  >  0  witn  respect  to 
still  anotner  policy.  Sensitivity,  tnen,  may  not  De  useful 
for  discussing  multiple  policy  issues.  It  is  nowever,  a 
useful  intuitive  term  for  describing  tne  lattice  nature  of  a 
poll cy . 

This  autnor  advances  tne  nypotnesis  that  all 
non-discreti onary  security  policies  may  be  represented  as 
lattice  policies.  A  simple  argument  is  offered  in  support  of 
tnis  nypotnesis  as  a  complete  proof  nas  not  been  developed. 

Non-dlscretlonary  security  policies  are  establisned 
external  to  tne  computer  system  environment.  As  sucn,  they 
define  some  form  of  benavior  between  subjects  and  objects 
from  which  tne  system  may  not  deviate  without  external 
authoritative  approval.  The  system  entities  (i.e.,  the 
subjects  and  objects)  must  oe  clearly  labeled  or  otherwise 
identified  with  respect  to  tne  policy.  Grouping  tnose  system 
entities  whose  labels  are  identical,  one  may  establish  a  set 
of  equivalence  classes  which  completely  partition  the 
systems'  entitles.  One  may  tnins  of  tnese  equivalence 
classes  as  labeled  by  the  access  classes.  Such  a 
partitioning,  for  ail  practical  policies  and  systems  is 
f ini te. 
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One  nay  tnen  examine  t&e  relations  between  access 
classes  witn  respect  to  tne  policies.  Enumerating  ail  tne 
relations  between  access  classes,  one  may  draw  a  graph,  sucn 
as  that  snown  in  figure  l,  witn  nodes  signifying  access 
classes  and  arcs  signifying  that  tne  access  class  of  tne 
higher  node  (i.e.,  closer  to  the  top  of  the  page)  is  more 
sensitive  (>)  tnan  tne  access  class  of  the  lower  node. 
Transitive  relations  need  not  be  drawn  as  tneir  inclusion  is 
implicit  and  does  not  affect  tne  grapn. 

Figure  1.  Disjoint  Partially  Ordered  Sets  and  Nodes 

If  any  cycles  are  discovered,  in  an  attempt  to  construct 
tne  grapn,  one  may  see  tnat  tne  specification  of  policy  is 
not  enforceable.  That  is  to  say,  for  some  cycle  of  access 
classes  A  >  B  >  ...  >  Z  >  A,  tne  information  sensitivity  of 
some  access  class  A  is  at  the  same  time  >  A  and  =  A.  This  is 
a  paradox.  Attempting  to  enforce  such  a  specification  is 
intuitively  nonsense!  So  if  one  is  to  nave  a 
noa-dlscretionary  security  policy,  viz.,  one  wnicn  is  to  be 
enforced  in  a  mandatory  fashion,  one  may  safely  assume  tnat 
tne  policy  will  specify  no  cyclic  relations  among  tne  access 
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classes.  Taerefore,  one  may  categorically  state  tnat  tne 
grapn  of  any  enforceable  non-dl sere tlonary  security  policy 
will  never  contain  any  cycles. 

Furtner  examining  tne  grapn,  one  can  observe  tnat  only 
two  general  structures  may  exist.  Tne  first  consists  of 
unrelated  nodes  (i.e.,  tnose  nodes  wnicn  are  singletons 
representing  access  classes  wi tn  no  relations  to  otner 
access  classes  in  tne  erapn).  Tne  otner  structures  are 
partially  ordered  sets  (some  of  wnicn  may  be  a  lattice). 


Figure  2.  Lattice  Structure 

If  tne  grapn  does  not  contain  a  least  upper  bound, 
(LOB),  one  may  arbitrarily  create  an  access  class  so 
designated  and  establlsn  tne  appropriate  relations  vitn 
respect  to  its  sensitivity  (see  figure  2).  Tnis  access  class 
may  also  be  referred  to  as  tne  "system  nign."  LiKevise,  one 
may  do  the  same  for  tne  greatest  lower  bound  (GLB)  wnicn  is 
generally  Known  as  tne  "system  low.”  Note  tnat,  neitner  tne 
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LUB  dot  tne  SLB  need  nave  any  entities  associated  with  tneir 
access  class.  By  forming  tnis  structure,  one  r.a s  established 
a  lattice. 

Thus,  all  non-discretionary  security  policies  are 
lattice  security  policies.  Non-discretionary  security 
specifications  tnat  generate  cyclic  structures  are  not  well 
formed  policies  and  as  sucn,  tneir  enforcement  car.not  te 
evaluated  nor  can  one  consider  sucn  a  specif ica tion  to  be  a 
policy  worthy  of  discussion. 

D.  SIMPLE  LATTICE  SECURITY  POLICIES 

A  policy  is  a  "simple  lattice  policy"  wnen  the  policy 
establishes  either  one  of  two  basic  lattice  structures.  The 
first  structure  is  formed  by  a  simply  ordered  (viz., 
linearly  ordered  or  totally  ordered)  set  of  access  classes. 
For  example,  some  policy  mignt  establish  a  simply  ordered 
structure  wnere  SECRET  is  more  sensitive  than  (>) 
CONFIDENTIAL  >  UNCLASSIFIED.  Policies  witn  simply  ordered 
sets  of  access  classes  are  called  "hierarchical  policies.” 

Tne  other  basic  lattice  structure  is  formed  by  a 
mutually  exclusive  set  of  access  classes.  For  example,  some 
policy  might  establish  a  mutually  exclusive  structure  wnere 
CRYPTO  is  not  related  to  (#)  NATO  *  NUCLEAR.  Those  policies 
with  mutually  exclusive  sets  are  called  "category  policies." 
One  should  note  that,  a  "compartment"  access  class,  e.g., 
CRYPTO-NATO,  is  formed  when  some  restricted  form  of  access 
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is  available  to  two  or  more  otnerwise  mutually  exclusive 
categories  of  information. 

Recall  t&at  a  lattice  security  policy  partitions  tne 
systems  entities  witn  respect  to  tneir  information  sensitiv¬ 
ities,  into  a  set  of  equivalence  classes  tnat  can  be  labeled 
by  tne  access  classes.  Consider  any  two  lattice  security 
policies,  P  and  P  ,  and  some  system  containing  a  non-empty 
set  of  entities,  A.  When  P  is  applied  to  tne  system, 
a  partition,  it  ,  is  establisned  creatine  tne  set  of 


equivalence  classes 
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tna  t 
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by 

tne 
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policy  P. 

It  readily  follows  tnat  ail  lattice  security  policies 
are  the  product  of  one  or  more  simple  lattice  policies.  The 
total  non-discretlonary  security  package  for  a  system  then, 
consists  of  some  set  of  simple  lattice  security  policies 
successively  refining  tne  systems  entities,  none  of  which 
may  produce  conflicting  policies.  This  is  shown  to  be 
particularly  useful  Knowledge  when  one  attempts  to  use  tne 
assignment  technique  as  a  means  of  security  validation. 
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E.  ACCESS  RELATIONS 

Any  specific  non-discretionary  security  policy  will 
distinguish  one  or  more  distinct  access  relations  between 
subjects  and  oojects.  Associated  witn  tnese  distinctions  one 
may  derive,  wnere  not  otnerwise  specified,  tne  set  of 
"access  rights”  wnlcn  may  be  accorded  to  tne  subject.  Tnese 
access  rights  specify  tne  liberties  wnicn  tne  subjects  may 
tage  witn  respect  to  tnese  objects.  Access  rights  are 
typically  mirrored  in  tne  "access  modes"  of  tne 
corresponding  protection  mecnanism.  Altnoueh  tnere  exists  a 
fine  difference  between  an  "access  right"  and  an  "access 
mode",  viz . ,  "access  rights"  are  associated  with  security 
policies  and  "access  modes”  are  associated  witn  tne 
protection  mechanisms  wnicn  enforce  tne  policy,  this 
discussion  frequently  refers  to  an  "access  rignt"  as  an 
"access  mode”  because  it  is  tne  access  mode  wnicn  must 
inevitably  be  questioned  when  evaluating  the  enforcement  of 
a  securl ty  policy  . 

The  enforcement  of  a  policy  is  fundamentally  limited  by 
tne  system's  granularity  of  access  wnicn  may  also  be  tnougnt 
of  as  the  system's  variety  or  richness  of  access  modes. 
Policies  tnai  prescribe  distinctions  not  recognized  by  tne 
access  control  mechanisms  must  be  enforced  in  an  overly 
restrictive  manner  or  ignored.  For  example,  a  policy 
addressing  a  concatenation  access  relation  cannot  ce 
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precisely  enforced  on  a  system  that  does  not  recognize  some 
form  of  append  access  mode. 

The  basis  of  all  security  enforcement  evaluation  lies  in 
tne  acceptability  of  an  access  relation.  An  access  relation 
is  defined  as  a  tuple  (subject,  access  mode,  object).  This 
tuple  signifies  taat  a  relation  between  tne  subject  and 
object  exist  sucn  that  tne  subject  is  permitted  to  access 
tne  object  witn  all  tne  privileges  associated  with  the 
access  mode.  The  problem  of  information  security  may 
generally  be  expressed  as  tne  problem  of  permitting  toe 
existence  of  only  those  access  relations  tnat  in  no  way 
violate  any  of  the  applicable  systems  policies. 

One  can  see  then,  tnat  tne  granularity  of  access  control 
within  a  system  is  dependent  upon  the  ability  to  distinguish 
attributes  of  subjects  and  objects  plus  tne  distinct  access 
modes  available.  The  primitive  access  modes  (i.e.,  those 
access  modes  tnat  are  not  decomposable  by  the  system) 
associated  with  the  design  of  the  system,  including  the 
protection  mecnanisms,  designate  tne  associated  rights 
accorded  to  an  access  request. 

When  tne  granularity  of  access  is  successively  refined, 
one  may  observe  two  conflicting  phenomena.  First,  the 
ability  to  distinguish  between  access  relations  is  more 
pronounced,  thus  allowing  for  greater  sophistication  and 
variety  in  policy  formulation.  The  problem,  however,  is  that 
tne  increased  distinctions  of  access  relations  increases  tne 
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complexity  of  tne  security  evaluation  process.  Systems 
designers  are  face!  wltn  tne  problem  of  striding  a  balance 
between  tne  granularity  ot  access  and  tne  complexity  of 
system  security  validation. 

This  nas  not  deterred  tne  efforts  of  many  systems 
designers#  nowever,  as  tne  granularity  of  subjects  and 
objects  is  quite  refined  in  many  systems,  unfortunately, 
sucn  systems#  almost  witnout  exception,  nave  failed  to 
enforce  even  minimal  non-dlscretionary  security  policies. 

Two  generic  access  modes  are  particularly  useful  in  tne 
discussion  of  security.  Tnese  are  [16J  "observe"  (tne 
ability  to  observe  information)  and  "modify"  (tne  ability  to 
modify  information).  Otner  access  modes  may  be  generally 
thought  of  as  a  finer  granularity  of  tnese  two  access  modes. 
Figure  3  illustrates  one  sucn  possible  set  of  primitive 
access  modes  and  bow  tney  are  associated  with  the  eeneric 
access  modes. 


Observe 


Modify 


Read  Execute  Write  Append 


Figure  3.  Generic  Access  Modes 


The  problem  of  computer  security  enforcement  can  be 
reduced  to  tne  problem  of  limiting  the  access  relations 
within  the  system  to  only  those  that  neither  directly  nor 


Indirectly  violate  the  systems  security  policies.  If  one  can 
establish  that  all  of  the  access  relations  permitted  in  toe 
system  are  acceptable  to  tne  policy,  one  has  established 
tnat  the  system  is  "secure." 

F.  ILLUSTRATION  OF  POLICIES 

In  reviewing  tne  computer  science  literature,  tnis 
author  was  unable  to  discover  any  illustration  forms 
appropriate  for  showing  the  features  of  non-discretionary 
security  policies  in  sufficient  detail  tnat  one  could 
readily  discern  all  permissible  access  relations  within  the 
system  simply  by  examining  tne  illustration  alone.  This 
section  presents  a  review  of  the  major  forms  examined  and 
their  failure  to  adequately  illustrate  access  relations.  It 
also  provides  two  proposed  alternative  forms  that  more 
clearly  illustrate  access  relations  of  a  system  in  a  manner 
which  leaves  no  doubt  as  to  the  nature  of  the  policy  and  the 
requirements  for  its  enforcement. 


LUB 


Figure  4.  Basic  Lattice  Form 

Figure  4  shows  a  representation  for  a  lattice  structure 
commonly  found  in  matnematicai  texts  [22,23J .  With  respect 


to  lattice  security  policies,  eacn  node  represents  an  access 
class  and  tne  arcs  signify  tnat  tne  node  nearer  the  top  of 
tne  page  represents  an  access  class  which  is  more  sensitive 
tnan  the  lower  nodes'  access  class.  Thus,  in  figure  4  one 
may  observe  tnat  4  >  D  and  B  #  A.  Sometimes  tnese  arcs  are 
labeled  by  ">"  symbols,  but  tnis  merely  tends  to  clutter  tne 
illustration  and  provides  no  additional  information.  Note 
tnat  this  form  provides  no  information  regarding  access 
relations  wltnout  some  examination  of  tne  policy  tnat  is 
being  illustrated,  e.g.,  one  cannot  readily  answer  tne 
question  "can  a  subject  of  access  class  A  write  to  an  object 
of  access  class  D?" 

The  form  shown  in  figure  5  [lid, 13]  ,  provides  basically 
tne  same  information.  Tnis  form  illustrates  tne  permissible 
information  flow  that  is  immediate  anl  non-reflexive  by 
means  of  directed  arcs.  Nodes  are  once  again  used  to 
represent  access  classes.  Access  relations  are  still 
non-discerni bie  by  examination  of  tne  illustration  alone. 


Figure  5.  Information  Flow  Form 
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Anot&er  form  wnicn  is  popular  in  capability-based 
protection  systems  researcn  [24] ,  illustrated  in  figure  5, 
is  called  a  protection  grapn  [20] .  Tnese  grapns  specify  eacn 
subject  as  a  solid  node,  and  eacn  object  as  an  empty 
node,  "0".  Tne  directed  arcs  between  nodes  specify  tne 
access  riettts  of  tne  source  by  tne  associated  labels.  This 
form  provides  an  eitremely  detailed  means  of  representing 
all  access  relations  witnin  tne  system.  Unfortunately,  tnls 
form  provides  sued  detail  tnat  an  illustration  of  any 
practical  system  becomes  exceedingly  busy.  Tnus  one  quicxly 
loses  tne  ability  to  distinguisn  between  access  classes  even 
when  they  are  clearly  labeled,  tfnat  is  needed  is  needed  is  a 
nigner  order  of  abstraction  for  tne  presentation  of 
practical  systems. 


r,w,a 


(Sitreps 


(Plant  Status 


(Repair  Status 
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An  access  relation  graph  clearly  snows  ail  permissible 
access  relations  specified  by  a  non-discretionary  security 
policy.  Reflexive  relations,  i.e.,  tnose  with  a  subject  of 
the  same  access  class  as  tne  object,  need  never  be 
specifically  cited  unless  all  access  modes  are  not  permitted 
within  an  access  class.  Antisymmetric  relations  are  clearly 


defined 

by  tne  directed  ar 

cs . 

Transitive 

relations  are 

inferred 

from  tne  patn  of 

two 

or  more 

antisymmetri  c 

rela  tions 

(viz.,  in  figure 

?  a 

subject  of 

tne  LUB  access 

class  may 

read  from  an  object 

of 

tne  3LB 

access  class). 

Therefore,  tne  form  meets  the  mathematical  requirements  for 
a  lattice  in  that,  all  access  relations  for  the  lattice 
(i.e.,  a  universally  bounded  partially  ordered  set)  are 
clearly  illustrated. 

In  its  most  delineated  case,  the  access  relation  graph 
is  reduced  to  a  protection  graph.  The  advantage  of  tne 
access  relation  grapn  over  tne  protection  graph  is 
simplicity.  Only  tne  access  relations  needed  to  represent 
tne  policy  are  shown.  Additionally,  complex  policies  and 
composite  policies  are  illustrated  in  one  simplified  form. 

Another  illustration  form  tnat  is  particularly  useful 
when  discussing  uniform  lattice  structures  (i.e.,  tnose 
access  relation  graphs  where  tne  access  modes  between  any 
two  antisymmetric  access  classes  are  identical)  is  tne 
linear  access  graph.  Such  a  graph  shows  tne  security 
label(s)  of  the  objects  (i.e.,  now  one  represents  tne 
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sensitivity  of  the  object)  and  denotes  the  access  modes 
available  to  subjects  of  varying  sensitivity  with  respect  to 
the  sensitivity  of  the  objects.  Figure  8(A)  illustrates  a 
simple  general  linear  access  grapn.  In  tnis  figure,  subjects 
with  greater  sensitivity  than  the  objects  sensitivity  would 
enjoy  the  use  of  access  mode(s)  2  when  referencing  that 
object.  Subjects  of  inferior  sensitivity  than  the  objects 
sensitivity  would  enjoy  the  use  of  access  mode(s)  1  when 
referencing  that  object.  Subjects  of  tne  same  sensitivity  as 
the  object  would  enjoy  access  modes  1  and  2  when  referencing 
the  object.  The  linear  access  graph  for  tne  tfultics  Ring 
Brackets,  first  pointed  out  to  the  author  by  R.  Schell,  is 
snown  as  an  example  of  a  familiar  policy  represented  in  this 
form  in  figure  8(B). 

t _ access  mode (s  )  1 _ , 

System  [Security  System) 

[  High _ _ Label  I  Low 

access  mode(s)  2 

(A) 

execute 

i  Bing  0  Htli  R2*  ] _ R3  , 

write _ J  call  as  a  gate 

read 


(B) 

Figure  8.  Linear  Access  Graphs 
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Tne  disadvantage  of  tae  linear  access  grapn  is  tnat  It 
may  oaly  be  used  for  Illustration  of  uniform  policies,  i.e., 
tnose  policies  wnere  tae  access  relations  between  any  two 
access  classes  (one  of  wnicn  is  more  sensitive  tnan  tae 
otner)  are  identical.  Tae  succinct  nature  of  tnis  form, 
however,  mates  it  possible  to  capture  tne  essence  of  a  class 
of  policies,  i.e.,  taose  waicn  may  be  described  by  tae  same 
linear  access  grapb,  witnout  going  into  ail  the  details. 

G.  EXAMPLE  POLICIES 

Having  discussed  tne  nature  of  policies  in  general,  one 
is  now  prepared  to  examine  several  specific  policies  of 
interest.  Sucn  a  discussion  logically  begins  witn  tne  two 
broadest  classes  of  security  policies,  i.e.,  compromise  and 
subversion. 

Modify _ 

Upper  |Seasitivi ty Lower  1 

I  Limits  _ Label  1  Limits 

5  bserve 

Figure  9.  Compromise  Policy. 

A  compromise  policy,  sometimes  referred  to  simply  as  a 
security  policy,  is  one  wnose  primary  intent  is  to  pronibit 
the  unauthorized  observation  of  information.  Figure  9  show 
tae  general  form  of  suca  a  policy.  Subjects  may  observe  only 
taose  objects  whose  sensitivity  is  less  than  or  equal  to  tae 
subject's  sensitivity  in  order  to  prevent  direct  observation 
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of  an  object  by  an  unauthorized  subject,  viz.,  the  Simple 
Security  Condition  [10J .  In  order  to  prevent  indirect 
observation  of  objects  by  unauthorized  subjects,  a 
sufficient  but  not  necessary  condition  establishes  that 
modification  of  objects  must  at  least  be  limited  to  those 
subjects  whose  sensitivity  is  less  than  or  equal  to  the 
objects  sensitivity,  viz.,  tne  (Security)  Confinement 
Property  —  also  lcnown  by  a  less  descriptive  title  as  tne 
’"-Property  [10]. 

A  subversion  policy,  sometimes  referred  to  simply  as  an 
integrity  policy,  is  tne  dual  of  a  compromise  policy.  The 
primary  interest  of  a  subversion  policy  is  to  prohibit  tne 
unauthorized  modification  of  information.  Figure  10 
illustrates  these  general  characteristics.  Subjects  may 
modify  only  those  objects  whose  sensitivity  is  less  than  or 
equal  to  tne  subject's  sensitivity  in  order  to  prevent 
direct  modification  of  an  object  by  an  unauthorized  subject, 
viz.,  tne  Simple  Integrity  Condition  [21J  .  In  order  to 
prevent  indirect  modification  of  objects  by  unauthorized 
subjects,  a  sufficient  but  not  necessary  condition  is  that 
observation  of  objects  must  be  limited  to  those  subjects 
whose  sensitivity  is  less  than  or  equal  to  the  object's 
sensitivity,  viz.,  tne  Integrity  Confinement  Property  [21J . 


Figure  10.  Subversion  Policy. 

Tne  Importance  of  subversion  policies  sttouid  not  te 
underestimated  [2,21j.  Changing  tne  course  or  an  ICB^,  for 
example,  snould  in  most  cases  require  a  more  sensitive 
authorization  tnan  simply  knowing  its  course.  Sucn  policies, 
nowever,  are  often  overlooked  in  many  Command,  Control,  and 
Communications  systems  [2] . 

Anotner  general  class  of  policies  teat  is  of  general 
interest  in  Security  Kernel  researca,  and  whose  title  was 
coined  during  tne  course  of  tnis  researen  effort  by  R. 
Scnell,  are  tae  "Program  Integrity”  policies  [4j .  Tne  notion 
of  program  integrity  stems  from  tne  desire  to  pronibit 
unauthorized  modification  of  executable  programs  by  less 
trustworthy  subjects.  In  tne  general  case,  one  wisnes  to 
ensure  tnat  tne  more  sensitive  programs  are  "tamperproof." 
In  otner  words,  one  wants  to  be  sure  tnat  tne  program  can  be 
"trusted"  to  perform  as  specified  and  can  not  be  "tricked" 
by  merely  reading  data  of  lower  sensitivity  or  "importance." 
For  example,  a  system  designer/programmer  may  wisn  to  insure 
tnat  his  programs  always  perforin  as  specified  in  botn  nis 
test  environment  and  in  any  application  environment.  Unlike 
a  strict  integrity  policy  [Zlj  ,  program  integrity  is  not 
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concerned  with  tae  Issue  of  general  observation  of 
information.  Program  integrity  is  tnerefore  less 
conservative  (and  tnus  more  "risxy")  tnan  Bibas  integrity 
policy.  Program  integrity  deals  only  witn  execution  and 
modification  of  information.  As  sucn,  figure  11  illustrates 
tae  general  form  of  a  program  integrity  policy. 


_ Execute _ 

Upper  | Sensitivi ty  Lower  1 

I  LI  ml  ts _  Label  I  Limits 

Modify 


Figure  11.  Program  Integrity  Policy. 


One  -nay  guarantee  tnat  no  direct  modification  of  a 
program  by  an  unauthorized  subject  (i.e..  a  direct  threat' 
is  possible  by  enforcement  of  the  following  condition  : 


Hauls _ Pj,<agx.ajn.Jpte.gElii  gaallil&fl.  :  if  a  subject 

has  modify  access  to  an  object,  then  tne  program 
integrity  of  the  subject  is  greater  than  or  equal 
to  tne  program  integrity  of  tne  object. 


Because  program  integrity  policies  are  concerned  with 
tne  execution  issue  (versus  tne  observation  issue  [ZlJ  ) , 
indirect  modification  of  information  is  not  strictly 
prohibited.  This  provides  a  certain  degree  of  flexibility, 
but  also  produces  a  certain  amount  of  risx  [19j .  Confinement 
of  execution  reduces  tne  risx  of  sucn  an  indirect  tnreat  but 
does  not  eliminate  it.  &  more  sensitive  subject  must  be 
trusted  not  to  modify  a  less  sensitive  object  either 
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intentionally  or  otherwise.  An  indirect  tnreat  occurs  when  a 


subject  executes  a  program  tnat  das  been  modified  by  a  less 
trustworthy  subject,  tnerefore,  one  wisnes  to  confine  toe 
execution  access  relations.  The  confinement  property  for 
program  integrity  is  defined  as  follows  : 


Program  Integrity  Confinement  Property  :  If  a 
subject  nas  execute  access  to  an  object,  tnen  tne 
program  integrity  of  tne  object  is  greater  t.nan  or 
equal  to  tne  program  inteerity  of  tne  subject. 


The  remainder  of  tne  section  discusses  tnree  policies  of 
general  interest  to  federal  ADP  users.  Any  computer  system 
designed  for  use  by  the  federal  government,  snould  as  a 
minimum,  consider  its  ability  to  enforce  these  policies. 

1 .  National  Security  Policy 

The  National  Security  Policy  classifies  information 
essential  to  tne  National  Defense  or  foreign  relations  of 
the  United  States.  The  President  of  the  United  States 
established  this  policy  in  Executive  Order  Number  12065 
dated  June  25,  1978  125] .  This  order  defines  three  levels  of 
classification  as  follows  : 


TOP  SECRET  :  That  information  or  material  the 
unauthorized,  disclosure  of  which  could  reasonably 
be  expected  to  cause  exceptionally  grave  damage  to 
the  national  security. 

SECRET  :  That  information  or  material  tne 
unauthorized  disclosure  of  which  could  reasonably 
be  expected  to  cause  serious  damage  to  the 
national  security. 
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CONFIDENTIAL  !  That  Information  or  material  tne 
unauthorized  disclosure  of  wnicn  could  reasonably 
be  expected  to  cause  damage  to  the  national 
security. 

Implicit  in  tnis  set  of  definitions,  tnere  also 
exists  a  classification  of  information  which  is  not 
classified.  Tnerefore,  one  nas  four  hierarchical  access 
classes  establisned  by  this  policy,  the  intent  of  which  is 
to  prevent  unauthorized  disclosure  (viz.,  observation)  of 
information  so  classified.  Figure  12  shows  the  access 
relation  grapn  for  tnis  compromise  policy  which  is  referred 
to  as  the  basic  National  Security  Policy. 

Executive  Order  12065  also  establishes  [25J  tne 
authority  to  originally  classify  new  information. 
Information  may  be  classified  Top  Secret  only  by  officials 
designated  in  writing.  Information  may  be  classified  Secret 
only  by  officials  wno  nave  Top  Secret  classifications  or  by 
officials  designated  in  writing.  Information  may  be 
classified  Confidential  only  ey  officials  witn  Top  Secret  or 
Secret  classifications  or  by  officials  designated  in 
wrltin*. 

In  order  to  obtain  access  to  classified  material, 
the  order  indicates  that  a  person  must  be  determined 
trustworthy  (granted  clearance)  and  tnat  access  is  necessary 


in  the  performance  of  that 

persons ' 

duties  ("need 

to  Know" 

). 

This  is 

a  discretionary 

poli cy , 

however,  and 

will 

be 

discussed 

no  further.  All  classified  material 

shall 

be 
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appropriately  and  conspicuously  marked  to  put  ail  persons  on 
clear  notice  tnat  tne  information  is  classified.  Classified 


material  no  longer  needed  shall  be  promptly  destroyed. 


Figure  12.  Basic  National  Security  Policy. 

2.  National  Integrity  Policy 

Tne  dual  of  tne  National  Security  Policy  is  the 
National  Integrity  Policy  [21J.  Motivation  for  sucn  a  policy 
comes  from  tne  desire  to  pronibit  subversion,  i.e.,  tne 
unauthorized  modification  of  information.  The  following  set 
of  Integrity  classes  nave  been  established  for  tnis  policy 
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[21] .  Implicit  with  this  classification  scheme,  one  also  nas 
information  that  is  not  classified. 

TOP  SECRET  :  That  information  or  material  the 
unauthorized  modification  of  which  could 
reasonably  be  expected  to  cause  exceptionally 
grave  damage  to  the  national  security. 

SECRET  :  That  information  or  material  the 
unautnorized  modification  of  vnicn  could 
reasonably  be  expected  to  cause  serious  damage  to 
the  national  security. 

CONFIDENTIAL  :  That  Information  or  material  tne 
unauthorized  modification  of  which  could 
reasonably  be  expected  to  cause  damage  to  the 
national  security. 

One  further  point  concerning  Integrity  Policies  must 
be  emphasized  before  one  proceeds.  Senerally  speaxing,  one 
has  a  *ood  notion  of  how  to  classify  information  with 
respect  to  security  and  unauthorized  observation,  but 
classification  with  respect  to  integrity  is  not  so  easily 
identified.  In  some  sense,  integrity  classification  must  be 
determined  by  the  object's  potential  importance  rather  tnan 
by  its  current  importance.  Consider,  for  example,  a  simple 
sine  function  tucJred  away  in  some  obscure  user  library.  If 
tnis  function  is  used  to  compute  trajectories  for  an 
inter-continental  ballistic  missile,  it  becomes  TOP  SECRET 
with  respect  to  the  National  Integrity  Policy,  wnereas,  it 
is  clearly  UNCLASSIFIED  with  respect  to  the  National 
Security  Policy.  Classification  of  information  with  respect 
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to  integrity  will  generally  require  considerable  planning 
and  foresight  [2J . 


3.  Privacy 


Tne  Code  of  Fair  Information  Practices  and  tne 


Privacy  Act  of  1974  establisned  the  following  basic  policy 
for  the  Federal  Government  [26J . 


(1)  There  must  be  no  personal  data  record-seeping 
systems  wnose  very  existence  is  secret. 

(2)  There  must  be  a  way  for  an  individual  to  find 
out  what  information  about  him  is  on  record  and 
now  it  is  used. 

(3)  There  must  be  a  way  for  an  individual  to 
correct  or  ammend  a  record  of  identifiable 
information  about  nim. 

(4)  There  must  be  a  way  for  an  individual  to 
prevent  Information  about  him  that  obtained  for 
one  purpose,  from  being  used  or  made  available  for 
other  purposes  witnout  nis  consent. 

(5)  Any  oreanization  creatine,  malntainine,  using 
or  disseminating  records  of  identifiable  personal 
data  must  guarantee  tne  reliability  of  the  data 
for  their  intended  use  and  must  taice  precautions 
to  prevent  misuse. 


All  information  systems  (including  computer  systems) 
used  by  tne  Federal  Government  are  subject  to  tnese  privacy 
requirements  and  must  incorporate  a  corresponding  set  of 
safeguards  wnen  tne  process  "Privacy  Information." 

These  three  policies  are  applicable  to  many  Federal 
data  processing  applications.  Numerous  other 
non-discretl onary  policies  exist  botn  in  tne  Federal,  State, 
and  Local  governments  and  in  private  industry.  It  nas  been 
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shown  In  this  section  that  these  policies  may  be  precisely 
descibed  using  access  relation  <?rapns  or  linear  access 
graphs  as  described  in  this  section.  Once  a  policy  has  been 
so  described,  a  precise  evaluation  of  its  enforcement  may  be 


III.  A  FORMALIZED  NOTION  OF  DOMAINS 


The  notion  of  a  "domain"  ftas  not  been  clearly  presented 
in  a  precise  manner,  nor  properly  defined.  Dennis  [5J 
introduced  the  concept  by  describing  a  "sphere  of 
protection."  Lampson  [6]  refined  tne  concept,  coining  tne 
term  "domain",  and  defined  a  domain  as  a  group  of 
capabilities  or  protected  names.  Scnroeder  [Bj  maintains 
Lampson's  definition,  but  provides  an  in-depth  discussion 
and  presentation  of  nis  ideas,  many  of  vnicn  were 
instrumental  in  tne  formulation  of  tne  concepts  presented 
nere.  Scnroeder  furtner  refined  tne  ideas  from  nis  tnesis, 
and  together  with  Saltzer  [14J,  defines  a  domain  as  a  set  of 
objects  tnat  may  be  accessed  by  a  principal.  This  definition 
is  the  most  commonly  accepted  today,  but  for  any  rigorous 
discussion  of  domains,  or  for  presentation  of  a  concept  such 
as  tne  assignment  tecnnlque,  a  more  formalized  definition  is 
needed . 

An  access  domain  A,  is  a  tuple,  (alt  a2,  ....  a^ ,  ..., 

),  where  n  is  the  number  of  primitive  ( non-decomposable ) 

access  modes  in  tne  system  and  ai  is  tne  set  of  all  objects, 

t  0,*  0_,  ....  0  .  ,  ...,  0  I ,  accessible  by  the  ”i”tn 

12  ]  m 

access  mode.  An  (access  mode)-domain  is  the  set  of  objects 
that  a  process  executing  in  tnat  domain  (i.e.,  a  subject) 
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has  the  right,  or  privilege  of,  accessing  according  to  the 
rules  for  that  particular  access  mode. 

Consider  the  following  examples  of  domains: 

A^ :  (Observe(O) :[A> ,  Modify(M) :[B>  ) 

A2:  (0:{A,B,C>,  M:{ A, B, C}  ) 

A3:  (0:{A,C.D> ,  M :  10}  ) 

A4:  (0 : {A, B, C , D} ,  M:{A,B,C,Dj  ) 

The  observe-domain  of  A.^  (denoted  as  OA.^  )  is  object  A 
and  the  modify-domain  MA^  is  object  B.  Note  that  simply 
referring  to  &1  as  containing  objects  A  and  B  would  not 
provide  much  insight  Into  the  true  nature  of  this  domain 
[14] . 

The  notion  of  "dominance"  with  respect  to  domains  was 
Introduced  by  Crohn  [16]  .  These  notions  are  refined  from 
security  dominance  and  integrity  dominance  to  a  more  general 
definition  of  dominance. 

A  domain,  Ai  dominates  (  •=»< )  A j  if  and  only  if  (iff) 
for  each  access  mode  "a",  aAj  aA^.  This  is 

particularly  useful  when  discussing  tne  reiationsnip 
between  domains  witn  respect  to  access  modes.  One  can  say 
tnat  for  some  a^,  a^  a^  iff  a^  £  a^. 

Continuing  with  the  previous  group  of  example  domains, 
oa4  Oa3.  Oa3  •<  OA^  «a4  oc  ma3,  kax  ma3,  a4 
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Similar  examples 


a*  A3  but  a3  does  not  dominate  a^. 
can  be  formulated  by  tne  reader. 

Dominance  domains  may  be  labeled  for  convenience.  In  tne 
Multics  system,  for  example,  the  dominance  domains 
established  by  tne  ring  mecnanism  were  Known  as  rings  and 
were  labeled  by  ring  numbers.  Scnroeder's  protection 
mechanism  also  uses  numbers  as  labels  for  dominance  domains 
[8J. 

The  systems  protection  mechanisms  establish  a  set  of 
dominance  domains  that  can  be  used  for  evaluating  tne 
protection  mechanisms.  These  dominance  domains  dominate  all 
domains  that  currently  exist  or  may  exist  within  the  system. 
If  one  can  establish  the  set  of  dominance  domains  for  the 
system  and  one  can  snow  that  tne  policy  noils  for  tnese 
domains,  then  one  can  show  that  the  policy  holds  for  all 
domains . 

A  mechanism,  in  the  most  general  sense,  is  sometning 
tnat  prevents  the  occurrence  of  certain  sequences  of 
operations  [15].  A  protection  mecnanism,  or  an  access 
control  mecnanism,  can  oe  defined  as  sometning  tnat  prevents 
the  unauthorized  access  of  Information.  In  the  broadest 
sense,  one  may  include  as  protection  mechanisms  sucn  things 
as  walls,  patrol  dogs  and  cypher  loclcs.  More  specifically, 
tnough,  a  protection  mecnanism  for  a  computer  operating 
system  is  a  procedure,  implemented  in  software,  firmware  (if 
there  is  such  a  thing)  or  hardware,  that  prohibits  tne 


access  of  objects  within  a  system  such  that  the  domain  of 
any  process  is  dominated  oy  some  particular  dominance  domain 
Inherently  established  by  the  protection  mechanisms. 


Figure  13.  Multlcs  Rings 

The  Muitlcs  Ring  Mechanism  [2SJ  Is  a  well  Known 
protection  mechanism  mat  provides  an  excellent  example  for 
the  discussion  of  dominance  domains.  One  may  tninic  of  these 
dominance  domains  as  a  set  of  concentric  rings  (illustrated 
In  figure  13),  each  numbered  in  Increasing  order  from  toe 
inner-most  ring  or  Kernel.  The  Kernel  is  conventionally 
assigned  ring  number  zero. 


The  Multics  Ring  Mechanism  determines  the  authorized 
access  of  a  subject  by  means  of  tne  current  ring  number  (r) 
that  specifies  the  dominance  domain.  Discrimination  among 
objects  is  by  means  of  a  ring  bracket.  Tne  ring  bracket  is  a 
three-tuple  (Rl,  R2,  R3)  where  R1 ,  R2,  and  R3  are  ring 
numbers  and  Rl  must  be  numerically  less  tnan  or  equal  to  R2 
which  is  less  than  or  equal  to  R3.  Access  is  characterized 
by  tne  rules  illustrated  in  tne  linear  access  grapn  snown  in 
figure  14. 


Execute  Call 

|  iRlng  0 _  iRli  R2> 1 

[  tfrl te  (Modify) 

Read  (Observe) 


(as  a  gate) 

“  R31 


Figure  14.  Multics  Ring  Mechanism  Linear  Access  Grapn 

Consider  now  a  system  that  uses  tne  Multics  Ring 

Mechanism  and  discriminates  among  tour  distinct  hierarchical 
rings  (0  tnru  3).  One  may  think  of  tne  domains  established 
by  this  system  as  AQ  ,  ,  A2  ,  and  A3 .  Consider  tne 

rules  of  access  established  in  figure  14,  waere  MAQ  is  tie 
objects  that  may  be  modified  by  a  process  in  domain  e.  Then 

MAq  <X  MA1  o<  ma2  <»c  MA3  .  Likewise ,  0Aq  <=k:  OAj^ 

0A2  0A3.  No  such  relationship  exists  for  execute  or 

call  (as  a  gate).  EA3  does  not  EA2,  as  2  for 

some  object  X,  In  which  case  X  €  EA2  but  X  it  EA3 . 

Likewise  CA3  (the  Call  (as  a  gate)  domain  of  A3  )  does  not 
**  CA2  as  R3  may  be  zero,  for  example,  in  which  case,  Rl 
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ani  R2  must  be  zero,  ruling  out  tne  possibility  of 
successive  dominance  call-domains. 

Note  taat  a  single  object  may  be  a  member  of  several 
dominance  domains.  Some  object  X,  with  rine  bracsets  (2,2,3), 
is  a  member  of  0a0 ,  0Alt  3a2.  Ma0  ,  Eaq  ,  Sa1  ,  Ea2 .  ana 
CA-j.  Therefore,  X  €,  AQ,  A^,  and  a3  .  Tnis  concept 
can  be  confusing  as  an  object  is  a  distinct  entity  generally 
represented  by  a  sinele  imaee. 

Tnis  section  nas  established  a  formal  definition  of 
domains  suitable  for  discussion  of  complex  domain  related 
issues.  Tne  notion  of  dominance  domains  was  introduced  and 
their  relationship  to  protection  mechanisms  established.  Tne 
Muitics  Ring  Mecnanism  provided  an  example  of  tne  means  by 
which  one  may  evaluate  tne  dominance  domains  established  by 
a  protection  mechanism.  Ravin*  formulaized  these  concepts, 
the  relationship  between  policy  and  mechanism  may  now  be 
investigated  in  an  organized  manner. 
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IV.  THE  ASSIGNMENT  TECHNIQUE 


This  section  Introduces  a  mathematical  framework  for 
evaluating  tne  reiatlonsnip  between  non-discretionary 
security  policies  and  protection  mecnanisms.  An  evaluation 
approach,  termed  ”Tne  Assignment  Tecnnlque",  utilizes  tne 
entity  -  relationship  model  in  establishing  an  assignment 
between  the  security  classes  of  information  established  by 
the  policy  constraints,  and  dominance  domains,  established 
by  tne  properties  of  tne  mecnanism.  Tne  assignment  technique 
provides  a  theoretical  foundation  for  assessing  the 
sufficiency  of  an  access  control  mecnanism  witn  respect  to  a 
well  formed  protection  policy. 

Tnis  section  begins  with  a  general  discussion  of  tne 
meaning  of  "assignment".  It  then  proceeds  to  Introduce  the 
assignment  tecnnlque  In  a  general  form.  The  section 
concludes  with  a  simplification  of  tne  assignment  technique 
made  possible  by  tne  lattice  nature  of  non-discretionary 
security  policies. 

A.  ASSIGNMENT 

Assignment  Is  the  establishment  of  a  reiatlonsnip 
between  two  entitles  such  that  the  first  entity  is  "assigned 
to"  tne  second  entity.  Matnematl cally ,  tne  term  assignment 
Is  not  significant.  One  could  easily  have  said  that  entity  1 
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is  related  to  entity  2.  Intuitively,  However,  assignment  is 
associated  witn  tne  connotation  ”to  fix  autnori tati veiy 
This  precisely  describes  the  manner  in  whicn  this 
relationsnip  is  establisned. 

Assignment  may  be  denoted  by  a  graph  from  the  first 
entity  to  the  second  as  follows: 


is  assigned  to" 

It  is  important  to  recognize  that  assignment  does  not 
alter  either  entity.  Assignment  is  merely  the  act  of 
associating  an  entity  or  set  of  entities  with  some  other 
entity  or  set  of  entities. 

Anotner  way  to  describe  assignment  is  in  terms  of  tne 
act  of  forming  a  tuple  (entity  1,  entity  2).  Additionally, 
one  may  thin*  of  assignment  as  a  function  (i.e.,  "is 
assigned  to")  where  the  assignment  process  establishes  a 
mapping  between  two  otnerwise  disjoint  entities.  Regardless 
of  the  context  of  discussion  or  the  symbolism  used,  one  may 
simply  tnin*  of  assignment  as  tne  act  of  associating  one 
thing  with  another. 

B.  THE  TECHNIQUE 

The  essence  of  the  assignment  technique  is  relatively 
simple.  First  of  all,  consider  the  nature  of  a  lattice 
security  policy.  Such  a  policy  partitions  tne  objects  of  a 
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system  into  a  lattice  of  equivalence  classes  labeled  by  tbe 
access  classes  as  discussed  In  section  II.  Eacn  equivalence 
class  can  be  thought  of  as  an  entity  tftat  may  be  subject  to 
assignment. 

Then  consider  a  mechanism,  which  establishes  a  lattice 
of  dominance  domains  as  discussed  in  section  III.  Each  of 
these  domains  can  also  be  thought  of  as  an  entity  that  may 
be  subject  to  assignment. 

Since  an  assignment  can  be  established  between  any  two 
entities,  one  can  maxe  an  assignment  between  the  equivalence 
classes  establisned  oy  a  lattice  security  policy  aud  tne 
dominance  domains  established  by  some  protection  mechanism. 
One  -nay  tnen  validate  that  (for  this  assignment^  tne 
mechanism  is  sufficient  to  support  this  policy.  This 
validation  is  made  by  examining  tne  set  of  access  relations 
that  the  mechanism  permits,  and  testing  for  possible 
violations  of  the  policy. 

Tne  assignment  technique  can  be  described  more 
systematically  as  follows: 

1)  Determine  if  tne  policy  is  a  lattice 
policy.  If  not,  the  assignment  technique  does  not 
apply. 

2)  Establish  the  set  of  equivalence  classes, 

{  ei ,  e2 »  •••»  e]< ,  . . . ,  ep  },  that  are 

associated  with  each  access  class. 

3)  Determine  tne  set  of  dominance  domains, 

{  ^2 •  •••»  Aq ,  .».,  Aq  } ,  that  are 

established  by  tne  systems  protection  mechanism. 
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4)  Make  an  assignment  from  ek  to  A  . 

5)  For  tttls  assignment,  examine  tne  access 
relations  permitted  by  tne  mecnanism,  testing  for 
possible  violations  of  tne  policy. 

6)  If  no  violations  can  exist,  tne  mecnanism 
is  sufficient  for  tne  policy  in  question. 

Step  4  of  tne  assignment  metnod  allows  for  considerable 
flexibility  in  tne  manner  in  wnicn  assignments  can  be  made. 
Any  possible  mapping  from  equivalence  classes  to  dominance 
domains  may  be  considered.  Tnis  flexibility,  nowever, 
Implies  considerable  effort  in  order  to  determine  tnat  a 
mechanism  is  not  sufficient  for  a  given  policy.  Fortunately, 
in  tnis  thesis  one  is  specifically  dealing  with  tne  security 
issue.  Because  of  this,  several  refinements  can  be  made  tnat 
greatly  simplify  this  task. 

C.  SIMPLE  ASSIGNMENT 

The  question  of  how  one  chooses  to  make  assignments 
(i.e.,  tne  cnoice  of  an  assignment  scneme)  may  seem 
relatively  complex  upon  first  inspection  of  the  assignment 
tecnnique.  Tne  problem,  nowever,  becomes  almost  trivial  wnen 
dealing  with  simple  non-discretionary  security  policies  as 
is  down  by  the  following  arguments. 

First  of  ail,  it  is  clear  that  tne  equivalence  classes 
(established  by  the  policy  constraints)  represent  distinct 
access  classes.  It  is  also  clear  tnat  tne  dominance  domains 
represent  distinct  sets  of  objects.  If  more  than  one 
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equivalence  class  were  assigned  to  tne  same  dominance 
domain,  taen  tnere  is  nothing  in  tne  mecnanism  to 
distinguisn  between  tne  access  classes.  Eut  tne  policy  does 
draw  some  distinctions  between  tnese  access  classes  (i.e., 
tnat  distinction  establisned  by  tne  definition  of  tne  access 
classes),  so  it  would  not  be  possible  to  enforce  tne  policy 
with  such  an  assignment.  All  such  assignments  can  be 
eliminated,  a  priori. 

On  the  otner  hand,  if  one  equivalence  class  was  assigned 
to  more  tnan  one  dominance  domain,  tnen  some  distinction  is 
being  made  for  an  access  class  that  is  not  specified  in  tne 
policy.  In  some  cases,  one  may  find  that  sucn  distinctions 
produce  violations  of  the  policy.  Altnoueh  other  cases  may 
not  do  so,  tnese  extra  dominance  domains  are  unnecessary, 
providing  distinctions  which  have  no  significance. 
Tnerefore,  tne  number  of  dominance  domains  of  interest 
established  by  tne  mechanisms  should  be  equal  to  the  number 
of  access  classes  established  by  the  policies. 

One  may  attempt  to  argue  that  tnere  may  exist  dominance 
domains  that  do  not  receive  an  assignment.  Such  domains, 
however,  must  be  eitner  empty  or  in  no  way  allow  for  an 
exception  to  the  enforcement  of  the  policy.  As  such,  one 
need  not  be  concerned  witn  tne  question  of  tneir  existence. 
One  need  only  concentrate  on  the  dominance  domains  for  which 
tne  assignment  was  made. 
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Considering  assignment  as  a  function,  it  has  been 
establisned  tnat  tne  only  assignment  scnemes  of  interest  are 
bijective  (i.e.,  a  one  to  one  and  onto  relationship  between 
the  access  classes  and  the  dominance  domains  122]).  This 
provides  some  improvement,  but  one  is  still  faced  with  at 
least  p!  possible  assignment  schemes  to  evaluate  (where  p  is 
tne  number  of  access  classes  estabiisned  oy  tne  policy). 

One  may  gain  considerable  improvement,  however,  by  only 
attempting  to  validate  one  simple  mechanism  witn  respect  to 
one  simple  policy  at  a  time.  lurthermore,  the  Knowledge  of 
partially  ordered  sets  may  be  used  to  maite  our  assignments 
in  a  very  selective  manner.  This  is  done  by  first  requiring 
tnat  tne  lattice  for  tne  dominance  domains  of  interest  tnat 
one  considers  for  assignment,  be  an  isomorphic  image  of  that 
for  the  equivalence  classes.  This  may  not  be  a  necessary 
condition,  however,  it  in  no  way  invalidates  the  results 
shown  (as  one  would  otherwise  be  dealing  with  an  isomorphic 
sub-image  estabiisned  by  the  mechanism),  and  it  is  nelpful 
in  this  discussion. 

ifhen  considering  tne  isomorphic  image  of  a  lattice,  the 
problem  of  assignment  is  reduced  to  a  question  of 
orientation.  One  may  either  assign  the  greatest  lower  bound 
of  tne  lattice  to  tne  greatest  lower  bound  of  tne  image,  or 
assign  the  greatest  lover  bound  of  the  lattice  to  the  least 
upper  bound  of  tne  image.  Lay  otner  assignment  would  not  te 
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acceptable  as  it  would  violate  the  ordering  or  tne  lattice 
or  of  tne  image. 

So  for  a  system  of  'V  isomorpoic  images  of  the  lattice 
established  by  the  policy,  one  need  only  consider  at  most, 
21c  assignment  schemes.  In  most  practical  cases,  when  tne 
mechanism  establishes  isomorphic  images  which  are  identical 
in  their  access  control  properties  because  of  the  uniform 
nature  of  the  mechanism,  one  need  consider  only  2  assignment 
schemes. 

The  Simple  Assignment  Theorem  r  For  any  simple 
lattice  policy  and  an  isomorpnic  image  established 
by  some  protection  mechanism,  no  more  than  two 
assignment  schemes  are  necessary  to  validate  the 
sufficiency  of  tne  mechanism  to  enforce  tne 
policy. 

Proof  Sketch  :  Tne  proof  proceeds  by  snowing 
that  two  assignment  schemes  are  reasonable  and 
that  all  others  are  not. 

1)  Mage  assignments  starting  from  tne  greatest 
lower  bound  (GLB)  of  the  lattice  to  the  GLB  of  the 
Isomorpnic  image.  Then  assign  every  reachable 
access  class  (l.e.,  tnose  of  unit  distance)  to  a 
reachable  dominance  domain  in  the  isomorphic 
image.  Next  assign  all  reachable  access  classes 
from  those  just  assigned  (which  are  not  already 
assigned)  to  a  corresponding  reachable  dominance 
domain.  Proceed  in  this  fashion  until  all  access 
classes  have  been  assigned.  An  assignment  such  as 
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mat  snown  in  figure  15  will  result,  wnere  tne  L'JE 
is  assigned  to  tne  L(JB,  A  is  assiened  to  A',  £  is 
assigned  to  B'f  and  so  fortn. 

This  assignment  is  a  valid  assignment  in  that 
an  assignment  can  be  made  from  tne  access  classes 
to  tne  dominance  domains  tnat  is  not  inherently 
incorrect  and  therefore  is  worthy  of 
consideration.  This  does  not  mean  tnat  tne 
protection  mechanism  is  sufficient  for  this 
assignment.  It  only  implies  tnat  sucn  an 
assignment  scheme  is  worthy  of  consideration. 


ACCESS  CLASSES  DOMINANCE  DOMAINS 


2)  Now  consider  a  second  practical  assignment. 
This  assignment  starts  from  tne  3LB  of  tne  lattice 
matting  an  assignment  to  tne  LOB  of  tne  isomorpnic 
image  and  proceeding  as  in  tne  first  assignment 
scheme.  Tne  resulting  assignment  is  illustrated  in 
figure  16  vnere  tne  LOB  is  assigned  to  tne  GLP,  A 
is  assigned  to  D',  D  is  assigned  to  A',  and  so 
fortn. 
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ACCESS  CLASSES  DOMINANCE  DOMAINS 


It  is  important  to  note  tnat  if  tne  lattice 
structure  is  not  uniform,  i.e.,  inverting  tne 
iattice  «rouli  not  proauce  tne  same  image,  tnen 
only  one  of  tne  two  aforementioned  assignment 
scnemes  will  ce  successful.  Tnis  limitation  occurs 
because  one  encounters  some  set  of  reacnable 
access  classes  during  assignment  tnat  nave  no 
co  rres ponding  reacnable  dominance  domains. 
However,  for  any  iattice  structure,  uniform  or 
otnerwise,  tnere  will  always  be  one  assignment 
scneme  to  an  lsomorpnic  image  tnat  is  wortnv  of 
consideration.  Tnls  leads  us  to  tne  following 
corollary. 

po rollary  1.  For  any  lattice  policy  and 
an  lsomorpnic  image  establisned  by  some 
protection  mecnanism,  tnere  exists  at 
least  one  valid  assignment  scneme. 

Proof  Sfcetch  (Corollary  1)  :  T&e  proof 
is  trivial  from  tne  definition  of  an 
Isomorphic  image.  If  a  lattice  has  an 
lsomorpnic  Image,  tnen  at  least  one 
ordering  of  nodes  in  tne  image  is 
identical  to  tne  ordering  of  nodes  In 
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tne  lattice,  tnerefore,  tnls  ordering  is 
worthy  of  consideration. 

3)  Now  consider  tne  assignment  of  tne  Gif 


access  class  to  any  dominance  domain  otner  than 
tne  LUB  or  tne  GLB.  If  tnis  is  done,  then  some 
otner  access  class  must  be  assigned  to  tne  LOB 
dominance  domain  and  still  another  access  class 
must  ne  assigned  to  tne  GLB  dominance  domain.  But 
if  the  isomorphic  image  is  to  maintain  the 
ordering  of  tne  access  classes,  tnen  there  exists 
some  ordering  which  is  not  valid  because  either 
tne  GLB  or  tne  LOB  of  tne  isomorphic  image  is  to 
be  considered  less  than  the  GLB  (in  the  image) 
wnicn  must  be  tne  least  element  (viz.,  least 
sensitive)  according  to  the  policy.  Therefore, 
such  an  assignment  can  never  be  valid.  Tnus  one  is 
reduced  to  the  task  of  considering  only  two 
possible  assignment  schemes  of  interest. 

One  can  further  simplify  the  assignment  technique  by 
combining  steps  4  and  b.  This  is  accomplished  by  malting,  an 
assignment  and  examining  all  access  relations  producible 
immediantly .  If  an  access  relation  is  not  valid,  one  can 
quickly  determine  tnat  tne  assignment  scheme  in  use  will  not 
validate  the  sufficiency  of  the  mechanism. 

Vnen  one  is  dealing  witn  more  complex  lattice 
structures,  one  is  faced  with  two  alternatives.  One  can 
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eitner  validate  tne  sufficiency  of  tne  mecnanism  for  eacn 
sub-policy,  establisnlng  tnat  if  eacn  sub-policy  is 
enforced,  then  the  complex  policy  is  enforced,  or  one  may 
choose  to  validate  tne  complex  policy  by  a  straight  forward 
assignment.  rfhen  using  a  straight  forward  assignment 
approacn,  one  must  remember  that  tne  Simple  Assignment 
Theorem  may  not  apply.  This  is  of  no  particular  consequence 
when  validating  a  protection  mecnanism  designed  for  a 
particular  policy  where  tne  assignments  are  chosen 
carefully.  Eowever,  establishing  the  insufficiency  of  an 
arbitrary  mecnanism  may  require  considerably  more  effort. 

The  basic  principles  associated  with  the  assignment 
tecnnlque  nave  been  presented  in  this  section.  One  may  now 
consider  some  simple  examples  that  illustrate  tne  usefulness 
of  assignment. 
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7.  mechanism  sufficiency  validation  by  assignment 


One  of  the  most  practical  uses  for  tne  assignment 
tecnnique  is  sufficiency  validation  of  protection  mecnanisms 
(i.e.t  validation  of  their  ability  to  enforce  security 
policies)  [4j .  In  contrast  to  other  validation  techniques 
[11,17],  tne  assignment  tecnnique  presents  a  method  whose 
mathematical  model  (i.e.,  the  entity-relationship  model)  is 
based  upon  the  nature  of  security  itself,  rather  tnan  other 
methods  which  adapt  the  nature  of  security  into  a  form 
designed  to  mesh  with  the  prescribed  format  of  some  well 
Known  mathematical  model.  This  section  discusses  mechanism 
sufficiency  validation  by  assignment  for  several  well  Known 
linear  non-discretionary  security  policies.  Although  the 
principles  discussed  in  this  section  apply  for  all  lattice 
security  policies,  only  linear  lattice  policies  are 
discussed  in  tnis  section  as  they  provide  a  sufficient 
foundation  for  the  discussion  of  any  lattice  policy  and  are 
more  clearly  illustrated  in  this  context. 

A.  MULTICS  RING  MECHANISM  ASSIGNMENTS 

Tne  question  of  tne  sufficiency  of  tne  Multics  Ring 
Mechanism  for  enforcement  of  the  basic  National  Security 
policy  was  tne  initial  problem  tnat  prompted  tne  current 
research  effort  and  led  to  tne  formulation  of  tne  assignment 
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technique.  It  is  appropriate  then,  that  this  analysis  be 
presented  as  an  Introductory  application  of  simple 
assignment. 


1.  Compromise  Policy 

As  stated  previously  in  section  II,  the  basic 
National  Security  policy  is  a  simple  lattice  security 
policy.  Figure  13  illustrates  tnis  policy. 

The  dominance  domains  of  the  Multics  Ring  Mechanism 
are  most  frequently  snovn  as  concentric  rings  numbered  in 
increasing  integer  order  from  the  innermost  ring  or  the 
Kernel.  The  security  Kernel  is  generally  assigned  ring 
number  0.  For  simplicity,  only  a  system  with  rings  0  thru  3 
is  shown  in  tnis  analysis.  Assignment  to  other  ring  numbers 
(such  as  2  thru  5  or  4  thru  ?)  will  produce  similar  results 
because  of  the  uniform  nature  of  the  Multics  Ring  Mechanism. 

Consider  as  the  first  assignment  scheme,  the 
assignment  of  the  TOP  SECRET  access  class  (the  least  upper 
bound  of  the  policy)  to  ring  0  (the  least  upper  bound  of  tne 
dominance  domains).  The  assignment  produced  is  illustrated 
in  figure  17. 

Next,  according  the  assignment  technique,  one  must 
examine  the  access  relations  permitted  by  the  mechanism  and 
test  for  possible  violations  of  the  policy.  In  order  to  do 
so,  one  must  first  examine  the  nature  of  the  Multics  Ring 
Mechanism  more  closely.  A  detailed  discussion  is  given  by 
Schroeder  [27J ,  however,  a  simple  explanation  of  the 


pertinent  details  as  used  in  this  discussion  is  provided  for 


those  readers  not  otherwise  familiar  with  Multics. 


Observe} 


is  assigned  to' 


s  assigned  to' 


Observe} 


is  assigned  to 


Observe} 


is  assigned  to 


f  Ring  0  ) 


Ring  1 


Ring  2 


Ring  3 


Figure  17.  Basic  National  Security  Assignment  1. 


T&e  Multics  Ring  Mecnanism  determines  tne  autnorized 
access  of  a  process  by  means  of  the  current  ring  number  ( r) . 
Tnus  a  process  which  is  executing  in  ring  number  1  would 
need  to  be  cleared  for  at  least  SECRET  information  according 
to  tnis  assignment  scneme. 

The  Multics  Ring  Mecnanism  discriminates  among 
objects  by  means  of  a  ring  bracket.  The  ring  dracret  is  a 
three-tuple  (  Rl,  R2,  R3)  where  Rl,  R2  and  R3  are  ring 
numbers  and  Rl  ,£R2,£.R3.  Access  to  objects  is  restricted 
such  that  tne  current  ring  of  execution  must  be  less  than  or 
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equal  to  R2  to  observe  Information  and  less  tftan  or  equal  to 
R1  to  modify  Information.  Figure  IB  snows  characteristics  of 
tne  ring  brackets  both  in  terms  of  the  access  modes  used  in 
this  discussion  and  tne  access  modes  used  in  Muitics. 

. Eiecute  (Observe) 

j  ■Ring  0 _ _  Hlli  R2p 

I  Write  (Modify)  _ 

Read  ( Observe )  ” 

Figure  18.  Multics  Ring  Mechanism. 

Continuing  now  with  tne  examination  of  access 
relations,  consider  an  object  that  is  classified  as  SECRET. 
Sucn  an  object  must  be  assigned  a  ring  bracket  such  tnat  it 
may  be  observed  by  processes  in  ring  0  and  ring  l  only.  R2 
must  tnerefore  be  1.  Tnls  presents  a  problem.  No  matter  wnat 
value  one  may  choose  for  Rl,  a  contradiction  occurs.  If  R1 
is  0  or  1  tnen  TOP  SECRET  processes  may  modify  SECRET  files 
violating  the  Confinement  Property.  If  Rl  is  greater  than  1, 
tne  restrictions  of  tne  ring  mechanism  would  be  violated 
(viz.,  Rl  >  R2).  Therefore,  one  can  conclude  tnat  this 
assignment  is  not  acceptable. 

Consider  now  tne  only  otner  potential  assignment 
scheme  where  the  greatest  lower  bound  of  tne  lattice  (the 
UNCLASSIFIED  access  class)  is  assigned  to  ring  0.  Tnis 
assignment  is  illustrated  in  figure  19. 


One  may  now  attempt  to  assign  ring  brackets  to  an 
object  classified  SECRET.  A  problem  occurs  Immediately.  One 


wants  processes  executing  in  ring  2  to  observe  SECRET 
objects,  but  tnen  a  process  in  rim  P  (i.e.,  an  UNCLASSIFIED 
process),  will  also  be  able  to  observe  tne  object.  Tae 
Simple  Security  Condition  cannot  be  enforced  witn  tnis 
assignment,  so  tae  assignment  scneme  is  not  feasible. 


Figure  19.  Basic  National  Security  Assignment  2. 


Since  neitfier  of  tnese  assignments  are  acceptable, 
and  snifting  tne  ring  assignments  numerically  would  yield 
similar  results,  one  can  see  tnat  no  assignment  win  be 
acceptable.  Therefore,  the  Multics  Ring  Mecnanism  is  not 
sufficient  to  enforce  the  basic  National  Security  policy  for 
compromise. 


2.  Subversion  Polic 


Tae  basic  National  Integrity  policy  L^l]  is  tne  dual 
of  tae  basic  National  Security  policy.  Wnereas  tae  security 
policy  is  concerned  wita  tne  unautnorizea  .  observation  of 
information  or  compromise,  tne  integrity  policy  is  concerned 
witn  tae  unauthorized  modification  of  information  or 
subversion  as  discussed  in  section  II. 

Consider  first  tne  assignment  of  tne  TOP  SECRET 
access  class  (tne  least  upper  bound  for  tne  lattice 
established  by  tne  policy)  to  Ring  0  (tne  least  upper  bound 
for  tne  dominance  domains  established  by  tne  mechanism ).  The 
assignment  produced  is  snown  in  figure  20. 


Jieure  20.  Basic  National  Integrity  Assignment  1. 
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One  may  now  examine  tne  access  relations  wnicn  tne 
Multlcs  Sine  Mecnanism  will  permit  (as  snown  in  figure  18) 
and  test  for  possible  violations  of  tne  policy.  In  so  doing, 
one  encounters  violations  almost  immediently.  One  wisnes  to 
nave  a  process  executing  in  Ring  1  (i.e.,  a  SECRET  process), 
for  example,  to  be  able  to  ooserve  TOP  SECRET  objects  in 
Ring  43,  but  tne  mecnanism  pronibits  tnis  observation. 
Additionally,  a  SECRET  process  could  observe  CONFIDENTIAL 
information  violating  tne  Integrity  Confinement  Property. 
Therefore,  tnis  assignment  scheme  is  not  feasible. 


Figure  21.  Basic  National  Integrity  Assignment  2. 

Consider  now  the  only  other  potential  assignment 
according  to  tne  Simple  Assignment  Tneorem) 
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scneme  (viz.. 


wnere  tne  TOP  SECRET  equivalence  class  is  assigned  to  Rin* 
3.  This  assignment  scneme  is  illustrated  in  figure  21 . 

Examining  tnis  assignment,  consider  an  object  tnat 
is  classified  as  SECRET.  Sucn  an  object  must  be  assigned  a 
ring  bracket  sucn  tnat  it  may  be  observed  by  processes  in 
Ring  0,  Ring  1  and  Ring  2  only,  so  R2  must  be  assigned  2. 
Rut  if  R2  is  2,  one  is  faced  witn  a  contradiction  in  tne 
assignment  of  Rl.  If  R1  is  assigned  0,  1  or  2,  tnen  a 
violation  of  tne  Simple  Integrity  Condition  occurs  because 
UNCLASSIFIED  subjects  may  tnen  modify  SECRET  objects.  If  Rl 
is  assigned  3,  tne  Ring  Bracket  constraints  are  violated. 
Therefore,  tnis  assignment  scneme  fails  to  provide  an 
assignment  where  tne  protection  mecnanism  can  enforce  tnis 
policy. 

According  to  tne  Simple  Assignment  Theorem,  there 
are  no  otner  assignments  wortny  of  consideration.  Therefore, 
tne  Mul ti C5  Ring  Mecnanism  is  not  sufficient  to  enforce  tnis 
policy  eitner. 

So  far,  it  nas  been  snown  tnat  tne  Muitics  Ring 
Mechanism  is  not  sufficient  to  enforce  the  basic  National 
Security  policy  nor  the  basic  National  Integrity  policy. 
However,  a  Muitics  Security  Kernel  nas  been  designed  [28,29J 
tnat  is  sufficient  to  support  both  of  these  policies.  This 
may  seem  to  be  a  contradiction  but  it  is  not.  Tne  confusion 
is  dissipated  when  one  asks  tne  question,  "Wna t  form  of 
policy  does  tne  Muitics  Ring  Mechanism  support?” 
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3.  Program  Integrity  Policy 

The  general  form  or  Program  Integrity  policies  was 
introduced  in  section  II.  Consider  now  tne  specific  program 
integrity  policy  shown  in  figure  22. 


Figure  22.  A  Program  Integrity  Policy. 

According  to  tnis  policy,  entities  are  partitioned 
into  one  of  four  access  classes  designated  as  User, 
Supervisor,  Utility  or  Kernel.  The  sensitivity  of  these 
access  classes  is  specified  as  :  Kernel  >  Supervisor  > 
Utility  >  User.  An  assignment  to  a  Multics  ring  structure  is 
made  as  shown  in  figure  23. 

Recalling  tne  characteristics  of  ring  brackets  shown 
in  figure  19,  "Max"  is  designated  as  Ring  0,  the  program 
integrity  access  class  (PI)  as  Rl  and  "Min”  as  R2.  One  may 
note  that  for  this  policy  any  choice  for  R2  greater  than  or 
equal  to  Rl  will  do.  Tnis  analysis,  however,  nas  fixed  R2  at 
3. 


According  to  tne  assignment  technique,  one  must  now 


examine  the  access  relations  permitted  by  the  mechanism  and 
test  for  possible  violations  of  tne  policy.  Unlifce  previous 
examples,  where  the  mechanism  was  obviously  not  sufficient 
to  support  the  policy  (i.e.»  only  a  single  counter-example 
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was  necessary)  tnis  example  examines  a  policy  tnat  Is  liicely 
to  fee  supported  by  tne  Multlcs  Ring  Mecnanism.  Knowing  tnis, 
it  seems  appropriate  to  present  a  more  careful  approach  for 


tne  validation  of  tnis  assignment. 


Figure  23.  Program  Integrity  Assignment  1. 

For  simplicity,  one  may  refer  to  eQ  (tne  first 
equivalence  class)  as  Kernel  (i.e.,  tne  access  class  tnat 
labels  tnis  equivalence  class  of  subjects  and  objects),  e, 
as  Supervisor,  e2  as  Utility  and  e3  as  User.  One  may  also 
refer  to  AQ  (tae  first  dominance  domain  establisned  by  tne 
Multics  Ring  Mecnanism)  as  Ring  0,  A^  as  Ring  1,  a2  as 
Ring  2  and  A3  as  Ring  3.  Tne  assignment  scneme  consists  of 
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assigning  eQ  to  aq  (Kernel  to  Ring  e),  e1  to  a  (Supervisor 
to  Ring  1),  e2  to  a 2  (Utility  to  Rice  2),  e3  to  a3  (User 
to  Ring  3).  One  can  now  evaluate  tbe  access  relations 
permitted  by  tne  Multics  Ring  Mechanism  and  compare  tnem 
witn  tne  policy. 

Examining  tne  read  access  first,  one  notes  tnat  the 
Multics  Ring  Mecnanlsm  provides  no  discrimination  for  read 
access  since  R2  is  fixed  at  3  for  ail  objects.  Thus  subjects 
in  aq,  a1#  A2  or  a3  may  read  objects  in  aq  ,  A..  A2 
and  A3 *  This  corresponds  with  the  access  rights  of  the 
policy  wnicn  states  tnat  subjects  in  eQ  ,  e1 ,  e2  or  e3  may 
read  objects  in  eQ  ,  e1 ,  e2  and  e3  .  Therefore,  the  mechanism 
is  sufficient  with  respect  to  tne  read  access  relations. 

Next,  examining  the  modify  access  relations  one  may 
observe  tnat  MAq  o*  MA.^  <x  ma2  c*C  Ma3.  Tnus  a  subject 
in  Aq  may  modify  objects  in  aq ,  A^ •  or  a3»  This 
corresponds  to  tne  access  rlgnts  of  tne  Kernel  access  class 
in  that  a  subject  in  eQ  may  modify  objects  in  eQ  ,  e  ,  e2  and 
e3 .  Examining  a1 ,  one  observes  tnat  a  subject  in  a3  may 
modify  objects  in  a.  »  A-  or  a,  Out  not  in  &  .  This 
corresponds  with  tne  access  rlgnts  of  tne  Supervisor  access 
class  in  that  a  subject  in  e.^  may  modify  objects  in  e1 ,  e2 
and  e3  but  not  in  eQ .  Examining  a2 .  one  observes  tnat  a 
subject  in  A2  may  modify  objects  in  a2  or  A3  but  not  in 
Aq  or  A^ .  This  corresponds  with  the  access  rights  of 
tne  Utility  access  class  in  tnat  a  subject  in  e2  may  modify 
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Finally 


objects  in  e 2  or  but  not  in  or  e  . 

examining  a3»  one  observes  tnat  a  subject  in  may  only 
modify  objects  In  A3«  This  corresponds  wit h  the  access 
rignts  of  the  User  access  class  in  that  a  subject  in  e 3 
may  only  modify  objects  in  e3.  Therefore,  the  Multics 
King  Mechanism  is  sufficient  to  support  this  policy  with 
respect  to  modify  access  relations. 

Next,  examining  tne  execute  access  relations  one  may 


observe  that  XA3 


XAn.  This  is  Just 


tne  inverse  of  tne  modify  access  relations.  Thus  a  subject 
in  a3  may  execute  objects  in  AQ,  A^  a2  or  a3.  This 
corresponds  to  tne  access  rights  of  the  User  access  class  in 


that  a  subject  in  e3  may  execute  objects  in  eQ,  elt  e2  and 
e3.  Examining  A2,  one  observes  that  a  subject  in  A2  may 
execute  objects  in  AQf  or  A2  but  not  in  a3»  This 
corresponds  with  tne  access  rights  of  the  Utility  access- 
class  in  that  a  subject  in  e2  may  execute  objects  in  eQ ,  e^ 
and  e2  but  not  in  e3.  Examining  A1 ,  one  observes  that  a 
subject  in  A-j^  may  execute  objects  in  AQ  or  A^  cut  not 
in  A 2  or  A 3 .  This  corresponds  with  tne  access  rights 
of  the  Supervisor  access  class  in  tnat  a  subject  in  e1  may 
execute  objects  in  e0  or  e^.  but  not  in  e2  or  e3 . 
Finally,  examining  AQ ,  one  observes  that  a  subject  m  aq 
may  only  execute  objects  in  AQ.  This  corresponds  with  the 
access  rights  of  tne  Kernel  access  class  in  tnat  a  subject 
in  eQ  may  only  execute  objects  in  eQ .  Therefore,  the 
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Multics  Ring  Mechanism  Is  sufficient  to  support  tnis  policy 
with  respect  to  execute  access  relations. 

So  one  may  observe  tnat  for  eacn  of  tne  access  modes 
(read,  modify  and  execute),  tne  Multics  Rina*  Mechanism  is 
sufficient  to  enforce  tne  policy.  Tnerefore,  for  tnis 
assignment,  no  violations  are  possible,  tnus  proving  that 
tne  Multics  Ring  Mecnanism  is  sufficient  to  support  tnis 
Program  Integrity  policy. 

B.  OTHER  P.I NS  MECHANISMS 

Tbe  Multics  Ring  Mecnanism  is  by  no  means  tne  only  form 
of  Ring  Mecnanism.  By  altering  tne  requirements  of  tne  Ring 
Brackets  and  tne  need  for  a  Gate  Keeper,  one  can  contemplate 
adapting  tfte  ring  mechanisms  to  meet  other  simple 
hierarchical  policies. 

Consider  using  the  assignment  shown  in  figure  17,  but 
altering  tne  means  of  discrimination  among  objects  such  tnat 
the  Ring  Bracket  is  a  singleton  (Rl).  Following  the  rules 
shown  in  figure  24,  one  can  adapt  this  ring  mechanism  to 
enforce  tne  basic  National  Security  policy. 

Modify 

i  KERNEL _ inj  MAX1 

Observe 

Figure  24.  Security  Rings. 
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Similary,  figure  25  snows  tae  rules  necessary  for  the 
sane  assignment  as  snown  in  figure  20  to  adapt  tnis  ring 
mechanism  to  meet  tne  basic  National  Integrity  policy. 

■  Observe _ 

i  KERNEL _ Hu]  MAX1 

Modify 

Figure  25.  Integrity  Rings. 

To  be  sure,  tnese  brief  suggestions  do  not  completely 
characterize  a  practical  protection  mechanism.  However,  it 
appears  that  ring  mechanisms  are  adaptable  for  tne 
enforcement  of  various  simple  hierarchical  policies. 

C.  CAPABILITY  MECHANISMS 

Considerable  effort  is  currently  underway  to  provide 
"Provabiy  Secure  Operating  System"  based  upon  the  capability 
mechanism  [30,31].  It  is  important  to  examine  what  form  of 
protection  capabilities  actually  provide. 

Capability  mechanisms  primarily  establish  two  dominance 
domains  that  are  enforced  by  this  system  hardware  mechanism. 
One  domain  consists  of  capabilities,  and  the  otner  is 
objects  that  are  not  capabilities  sucn  as  segments  and 
directories.  A  process  taites  no  note  of  these  dominance 
domains,  however,  because  all  processes  have  access  to 
capabilities  as  well  as  other  types  of  objects.  So  with 
respect  to  a  process,  the  capability  mecnanism  provides  no 
inherent  partitioning  of  the  system  entities  at  ail.  In 
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fact,  in  trying  to  determine  tne  structure  of  dominance 
domains  for  non-capability  objects,  one  encounters  a 
veritable  "spaghetti  bowl”  of  domains,  devoid  of  any 
inherent,  unifying  structure.  Thus  a  capability  mechanism  is 
of  itself  not  sufficient  for  the  enforcement  of  any 
non-discreti  onary  security  policy.  Enforcement  of 
non-discretionary  security  policies  (i.e.,  those  of  primary 
interest  to  National  Defense)  must  be  accomplished  by  some 
otner  add-on  mechanism. 

TQis  is  not  to  say  that  a  capability  mechanism  is  not 
useful.  For  example,  the  mechanism  can  protect  a  security 
Kernel  in  mucn  tne  same  way  as  rings  protect  tne  Kernel  in 
the  Muitlcs  design. 

The  usefulness  of  the  assignment  tecnnique  in  validating 
the  suitability  of  a  protection  mechanism  to  enforce  a 
security  policy  has  been  examined  in  this  section.  The 
validity  of  tne  assignment  tecnnique  has  been  estanisned. 
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71.  CONCLUSION 


This  research  nas  explored  the  foundations  of 
non-discreti onary  security,  discovering  an  effective 
methodology  for  assessing  tne  sufficiency  of  a  protection 
mechanism  to  enforce  a  non-discreti onary  security  policy.  By 
formalizing  the  notion  of  a  domain  [6,?J  ,  and  using  a  formal 
notion  of  non-discretionary  security  [3],  the  inseparable 
nature  of  protection  mechanisms  and  security  policies  has 
been  established.  This  section  considers  some  future 
directions  for  researcn  and  summarizes  tne  principle 
findings  of  the  autnor. 

A.  FUTURE  DIRECTIONS 

Although  this  author's  Investigation  has  provided  seme 
structure  to  the  complex  nature  of  security,  considerable 
researcn  is  still  needed.  Tne  relationship  between 
protection  mechanisms  and  other  operating  systems  mechanisms 
is  not  clear.  Sucn  issues  as  seriaii za till ty , 
synchronization  and  distributed  processing  may  add  new 
dimensions  to  tne  meaning  of  protection.  Fundamental 
limitations  regarding  implementation  details  remain  untenown. 

Additionally,  one  can  consider  tne  formalization  of 
policy  specifications  in  general.  Can  the  enforcement  of  any 
policies  other  tnan  lattice  policies  be  evaluated?  Can  ail 
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enforceable  policies  be  represented  in  some  common  form  sucn 
as  a  lattice? 

One  of  tne  most  difficult  problems  in  actually  enforcing 
any  security  policy  is  tne  maintenance  of  unique 
non-forgeabie  attributes  [6j  associated  with  tne  subjects 
and  objects,  A  mechanism  for  maintaining  the  uniqueness  of 
tnese  attributes  may  be  called  an  "isolation  mecnanism” 
because  it  isolates  those  subjects  that  may  access  tnese 
attributes  from  tnose  that  may  not.  Tnis  does  not  prevent 
sharing  of  objects  but  simply  provides  a  means  of  isolating 
tnese  attributes  from  general  unprotected  usage.  Botn  tne 
capability  mecnanism  130,31]  and  the  notion  of  a  gate 
(mecnanism)  [9,28J  appear  to  be  isolation  mecnanisms.  k 
comprehensive  study  of  tnis  problem  is  beyond  the  scope  of 
this  discussion.  However,  a  few  observations  concerning 
isolation  noted  during  this  research  are  provided. 

Tne  fundamental  principles  upon  wnicn  an  isolation 
mechanism  must  rely  is  tne  notion  of  a  segment  (i.e.,  an 
atomic  unit  of  information  storage  for  wnicn  tne  access 
class  is  identified)  and  tne  tranquillity  principle  (i.e., 
tne  notion  tnat  tne  access  class  for  a  subject  or  an  object 
does  not  change  during  tne  course  of  computations)  [17J  .  If 
tnese  two  principles  are  not  enforced,  it  is  not  clear  now 
one  may  evaluate  the  enforcement  of  any  non-discretionary 
security  policy. 
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Tne  tranquillity  principle  does  not  strictly  apply  to 
processes.  In  Multics,  for  example,  processes  nad  several 
domains  of  execution.  However,  since  a  subject  is  defined  as 
a  process-domain  pair,  one  mignt  at  first  suspect  tnat  a 
process  executing  in  multiple  domains  does  not  present  a 
security  problem.  Tnis  is  not  always  tne  case,  particularly 
when  dealing  with  policies  that  attempt  to  limit  the 
information  flow  [13 J . 

When  attempting  to  enforce  tne  National  Security  Policy 
in  a  multi-user,  multi-process  environment,  wnere  a  process 
executes  in  a  sequential  fashion  (i.e.,  the  process  is 
serializable)  one  can  do  no  better  tnan  to  allow  a  process 
to  proceed  to  its  "nigh  water  mart"  and  then  terminate  at 
that  level.  Any  attempt  to  revert  to  a  less  sensitive  access 
class  will  result  in  a  potential  compromise.  For  example, 
consider  the  compromise  technique  shown  in  figure  26. 

In  this  example,  a  malicious  agent  utilizes  the  feature 
of  sequential  processes  and  the  basic  PV  synchronization 
mechanism  [33]  to  take  tne  "info”  in  Dominance  Domain  2  and 
copy  it  into  Dominance  Domain  1.  In  order  to  do  so,  the 
agent  calls  procedures  placed  in  the  "High”  domain  by 
subversion  [3],  relyine  only  upon  one  process  (i.e.,  PP.OCESS 
0  or  PROCESS  1)  to  return,  thus  providing  the  information  in 
binary  form  to  tne  "Low”  domain.  Thus  by  serialization  and 
process  synchronization  alone,  tne  isolation  of  the 
dominance  domains  has  been  compromised. 
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Dominance 

Domain  1  (  Low  ) 

Dominance 

Domain  2  (  Hi?n  ) 

Initial  State: 

Info  101  ...  ^ 

Gotlt  0 

Pointer  l0000ll 

Execution : 

PROCESS  S  ( "Syncaronizer" ) 

Lit  p ( 1 ) ; 

Gotlt  :=  l; 

Pointer  :=  Pointer  +  l» 

P(2); 

Gotlt  :=  0? 

v(3); 

f(4); 

GO  TO  Li; 

PROCESS  0  (“Get  a  Zero") 

L2:  CALL  ZeroProc 

IF  Gotlt  =  0,  THEN 

Copy(Pointer)  :*  0; 

V(1)I 

V(2U 

P(3); 

GO  TO  L2> 

PROCESS  1  ( "Get  a  One”) 

L3:  CALL  OneProc 

IF  Gotlt  ■  0, 

THEN  Copy( Pointer )  :  =  1» 
v(i); 

▼  (  2); 

p<4); 

GO  TO  L3 » 

JSexo.Lr.Gc 

IF  Inf 0 (Pointer )  *  0, 
then  return; 

Sis  IF  Gotlt  *  0, 

THEN  GO  TO  S 1  * 
RETURN. 

OneProc 

IF  Info  (Pointer )  =  1, 
THEN  RETURN; 

S2 :  IF  Gotlt  =  e, 

THEN  GO  TO  S2; 
RETURN. 

Final  State: 

Info  101  ... 

Figure  26.  Serialization  Problem. 
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Note  tnat  were  tne  processes  to  act  independently  In 
eacn  dominance  domain  (i.e.,  processes  are  serializable  only 
wi?n  respect  to  a  given  dominance  domain  or  syncnroni zati on 
between  two  processes  is  not  possible)  tnis  compromise  couid 
not  occur.  In  general,  tnis  example  snows  tnat 
syncnroni za ti on  of  processes,  serialization  of  processes  and 
secure  computations  are  fundamentally  related  in  some 
fasnion.  Tne  exact  nature  of  tnis  reiationsnip  is  not  clear. 

£.  RESULTS 

Tne  assignment  tecnnique  nas  been  snown  to  be  a  useful 
method  for  validating  tne  sufficiency  of  a  protection 
mecnanism  to  enforce  non-discretlonary  security  policies. 
This  method  provides  considerable  insight  into  tne  nature  of 
access  control.  One  may  observe  tnat  non-discretionary 
security  is  dependent  only  upon  tne  dominance  domains 
estaolisned  by  tne  systems  mechanisms  and  tneir  associated 
permissible  access  relations.  Tne  nature  of  tne  computation 
is  of  no  concern. 

Any  non-discretionary  security  policy  for  wnicn  tne 
access  classes  and  access  relations  can  be  enumerated,  can 
be  enforced  in  a  theoretical  sense.  Actual  implementation, 
.however,  is  dependent  upon  tne  systems'  isolation  mechanism. 
No  policy  can  be  enforced,  in  a  practical  sense,  unless  tne 
system  can  maintain  unique  non-f orgeable  attributes. 
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Protection  mecnanisms  lnnerentiy  "mirror"  tne  policies 
tnat  they  enforce.  Non-discretionary  Security  policies  form 
a  lattice  of  access  classes  tnat  may  be  mapped  to  an 
lsomorpnlc  Image  of  dominance  domains,  inherently 
established  by  the  protection  mecnanism.  Since  this  has  ceen 
shown,  one  need  not  illustrate  separate  lattices  for  both 
policy  and  mechanism.  One  unified  description  for  both  the 
lattice  policy  and  its  image  established  by  the  protection 
mechanism  is  sufficient  for  general  systems  design 
considerations . 

One  may  also  consider  approacning  tne  assignment 
technique  from  tne  mechanism  point  of  view.  The  question 
tnen  becomes,  "Given  some  general  Protection  Mecnanism,  what 
form  of  policies  will  it  support?"  An  absolute  answer  to 
tnis  question  is,  in  general,  not  available.  However,  one 
can  make  an  evaluation  for  tnose  policies  that  are  of 
current  interest.  Tnus,  tne  assignment  tecnnique  gives  one  a 
forum  in  which  to  consider  the  usefulness  of  protection 
mecnanisms  for  specific  policies  of'  interest. 

"Uniform  protection  mecnanisms,"  i.e.,  tnose  mecnanisms 
forming  lattice  structures  of  dominance  domains  wnere  tne 
access  relations  between  any  two  antisymmetric  dominance 
domains  are  identical,  may  be  represented  by  linear  access 
graphs  in  tne  same  manner  as  a  policy.  Wnen  tne  linear 
access  grapn  for  tne  policy  is  similar  to  tne  linear  access 
grapa  for  the  mechanism,  one  can  see  that  for  a  carefully 
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cnosen  assignment  scneme,  tne  protection  mecnanism  will 
enforce  tne  security  policy. 

One  may  consider  tne  development  cf  a  taxonomy  of 
uniform  protection  mecnanisms  cased  upon  tne  nature  of  tne 
access  control  tnat  eacn  enforces.  Sucn  a  taxonomy  is  ceyond 
the  scope  of  this  discussion,  however,  the  linear  access 
grapns  illustrated  tnrougnout  this  text  may  De  neipful  in 
initiating  sucn  an  effort. 

The  protection  provided  Dy  tne  Multics  Ring  mecnanism 
appears  to  he  precisely  tne  issue  tnat  Wuif,  Jones  and  tne 
other  designers  of  tne  "HYDRa"  system  were  attempting  to 
understand  [18J .  They  introduce  their  discussion  by  first 
sayine  : 


"Protection  is,  in  our  view,  a  mechanism."  [iej 


Tnelr  discussion  tnen  proceeds  to  mate  tne  following 
general  statement  relative  to  tne  Multics  rings: 


’Our  rejection  of  hierarchical  system 
structures  and  especially  ones  which  employ  a 
single  hierarcnical  relation  for  all  aspects  of 
system  interaction,  is  also,  in  part,  a 
consequence  of  the  distinction  between  protection 
and  security.  A  failure  to  distinguish  tnese 
issues  coupled  with  a  strict  hierarchical 
structure  leads  inevitably  to  a  succession  of 
increasingly  privileged  system^  components,  and 
ultimately  to  a  "most  privileged"  one,  which  gain 
their  privilege  exclusively  by  virtue  of  their 
position  in  tne  hierarchy.  Sucn  structures  are 
Inherently  wrong  ..."  [i9J 
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Had  the  assignment  tecnnique  been  available  to  tne 
autnors  of  tne  above  statement,  tney  would  nave  been 
afforded  a  means  of  expressing  their  views  more  precisely 
tnan  tne  ambiguous  pnrase  "innerently  wrong".  Tne  assignment 
tecnnique  provides  a  precise  means  for  clearly  formulating 
sucn  an  observation  and  evaluating  its  validity.  As  snown  in 
section  7,  and  in  agreement  witn  tfulfs'  statement,  tne 
Multics  Hlng  Mecnanism  is  "innerently  wrong"’  witn  respect  to 
compromise  policies.  On  tne  otner  nand,  tne  Multics  Rine 
Mecnanism  is  ".just  rignt"  as  a  means  of  enforcing  a  program 
integrity  policy  or  assisting  in  tne  enforcement  of  tne 
systems  Hierarchical  as  well  as  non-hierarchical  security 
policies  (viz.,  via  Security  Kernels). 

Additionally,  in  tne  same  report  [iej  tne  autnors  mate 
tne  following  observation  witn  respect  to  tneir  overall 
design  methodology  : 

"Among  tne  major  causes  of  our  inability  to 
experiment  witn,  and  adapt,  existing  operating 
systems  is  tneir  failure  to  properly  separate 
mecnanisms  from  policy."  [iej 

The  assignment  tecnnique  has  shown,  however,  that 
lattice  security  policies  and  protection  mecnanisms  tnat 
enforce  these  policies  are  inextrlcablely  related. 
Recognizing  tnis  inseparabiii ty  should  provide  considerAti-fc^-^ 
Insight  into  current  efforts  in  tnis  area. 
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Overall,  assignment  researcn  nas  provided  a  matnemati cal 
methodology  for  unifying  tne  discussion  of  security  related 
Issues.  One  may  now  properly  refer  to  an  access  mode  as  a 
realization  of  an  access  rlgnt,  a  dominance  domain  as  a 
realization  of  an  access  class  and  a  protection  mecnanlsm  as 
a  realization  of  a  security  policy. 
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